On Wed, May 24, 2017 at 8:01 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> On 5/24/2017 5:11 PM, Levi Morrison wrote: > > On Wed, May 24, 2017 at 9:04 AM, Larry Garfield <la...@garfieldtech.com> > > wrote: > > > >> 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. > >> > >> --Larry Garfield > > > > > > 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. > > > > What is wrong with `ramsey/uuid`? > > Well, absolutely nothing. I personally would consider it > over-engineered, but that is no real reason. My implementation is after > all not an attack on a well maintained Composer package. The fact that > this package was downloaded almost 10 million times however is an > indicator that that functionality is required a lot. What is an STD for? > Exactly, to provide things that are needed everywhere. This is exactly > the reason why I want to see UUIDs as part of PHP's STD. > Indeed: UUIDs are much, much, much needed feature. > What is wrong with PECL's uuid? > > Of course I know about that package. The problems I have with it are > simple: > > - It just exposes a C API to userland, without considering that PHP is > becoming less and less procedural. > For once, I must say that I disagree with having an OOP API defined in core. This can exist in userland, so it probably should. Internal classes, their reflection, behavior, inheritance model, etc are full of quirks. There's nothing wrong in returning a string, then having a userland lib make it into a UUID value object: it actually is better for everyone's sanity. It would (probably) be better to stop at the function that actually generates the identifier, then having the boxed value defined in userland anyway. Yes, we lose the type hinting, but damn are internal classes ugly. If you must keep the object style, make it `final`, so at least we won't have people extending this thing for no good reason at all :-P Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
