Re: [RFC] [Discussion] UUID

From: Date: Wed, 24 May 2017 15:29:36 +0000
Subject: Re: [RFC] [Discussion] UUID
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-99147@lists.php.net to get a copy of this message
Am 24.05.2017 um 17:11 schrieb Levi Morrison:
On Wed, May 24, 2017 at 9:04 AM, Larry Garfield <larry@garfieldtech.com> wrote:
On 05/24/2017 04:31 AM, lists@rhsoft.net wrote:
Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:
Hey internals!
I haven't written the RFC yet,
Please don't forget to include in the RFC a justification for why this should be part of PHP core, rather than a library
because as developer in reality you can not use and rely on features which needs to install some pecl-library when it is supposed to be used on typical hosting packages
It doesn't have to be a PECL library. I agree that a project requiring a PECL library greatly limits its potential reach, but with Composer user-space libraries are totally easy to install. There's a nice and popular UUID implementation already: https://packagist.org/packages/ramsey/uuid Note: That doesn't mean adding UUID functionality to PHP core/standard lib is a bad idea; discussing that is fine. But the "no one will be able to use it otherwise" argument is substantially less compelling than it was even 5 years ago.
By the way there already is a PECL package for a UUID library: https://pecl.php.net/package/uuid. I would like to see compelling reasons why we shouldn't rally around that package because when you end in a library/extension for each and every trivial function your codebase becomes a mess - why not PECL i have explained before the post you quoted and why composer as it is working nwo is a no-go in the follow-up response
not that i care much of *that* function but when in the future every functionality ends in pecl and/or composer, well, my list what not to touch will grow in the same speed we maintain a large codebase (250000 LOC) over 15 years and the only 3rd party library is 'phpmailer' and besides php-pecl-apcu and php-pecl-imagick on prodcution machines there are no 3rd partly librarie and won't be that soon - not interested in the mess 10 years later while currently i can deploy hundrets of instances with a self-contained deployment software using the same framework as the application and it's modules and build/test a php-build whithn a few minutes be it 7.0.x, 7.1.x, 7.2.x with every single external dependency that becomes harder

« previous php.internals (#99147) next »