Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99156
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.68 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <be5db50a-bc70-2cfe-5a0a-dc0ef15360ba@fleshgrinder.com>
References: <e71637c6-db4a-7f29-ae08-89625eae8b53@fleshgrinder.com>
 <CA+kxMuTV7p14HbDpEQrwJKG3soUgxXV5BEs6WHgPtSOmjc2grQ@mail.gmail.com>
 <f9c91d81-097b-680e-904a-126ffee16b19@rhsoft.net> <ba50cf2d-6744-e78f-18be-e1d65990f0d9@garfieldtech.com>
 <CAFMT4NpNmkpfcWXsMydxDbULV9iNTe9BJxYdFdHdD1H36P1p6w@mail.gmail.com> <be5db50a-bc70-2cfe-5a0a-dc0ef15360ba@fleshgrinder.com>
Date: Wed, 24 May 2017 20:09:34 +0200
Message-ID: <CADyq6sKta5ngCkQc3tZZ5Pw3GqW93Lk283ofeuPMf6c7fjyCLg@mail.gmail.com>
To: Fleshgrinder <php@fleshgrinder.com>
Cc: php-internals <internals@lists.php.net>, Larry Garfield <larry@garfieldtech.com>, 
	Levi Morrison <levim@php.net>, lists@rhsoft.net, Remi Collet <remi@fedoraproject.org>
Content-Type: multipart/alternative; boundary="001a1145b054e7d5c905504902f5"
Subject: Re: [PHP-DEV] [RFC] [Discussion] UUID
From: ocramius@gmail.com (Marco Pivetta)

--001a1145b054e7d5c905504902f5
Content-Type: text/plain; charset="UTF-8"

On Wed, May 24, 2017 at 8:01 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 5/24/2017 5:11 PM, Levi Morrison wrote:
> > On Wed, May 24, 2017 at 9:04 AM, Larry Garfield <larry@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/

--001a1145b054e7d5c905504902f5--