Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99193
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6sK1p+Ruf9NT1zbAiz-QjBGT_5hitNu4J0ns6+o0Y8gFYg@mail.gmail.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> <CADyq6sKta5ngCkQc3tZZ5Pw3GqW93Lk283ofeuPMf6c7fjyCLg@mail.gmail.com>
 <e47a2c34-b6f3-66de-1f03-6753d5b1d4ea@fleshgrinder.com> <CADyq6sLvmYS0oqhSTzq13V-9604WSOdqmaeM5yVGhgQGKpjjxQ@mail.gmail.com>
 <CAJOjSBi0ZrmXoDWv4iMTgXCLc74QuCWfbjK4CMbhCSPx5YC7LA@mail.gmail.com>
 <a6ea0770-9e66-3556-b0a6-d056adb3aef4@fleshgrinder.com> <CAF+90c_W0rDSd=0baaWVqFYkMGycf6X32CC5JOcpkWrx=VP_ZQ@mail.gmail.com>
 <CADyq6sK1p+Ruf9NT1zbAiz-QjBGT_5hitNu4J0ns6+o0Y8gFYg@mail.gmail.com>
Date: Fri, 26 May 2017 10:30:21 +0200
Message-ID: <CAF+90c9y0e+BsSSmLWJ3KHMfK0EvPEJ5ppDAnmqMzjahL0UjBw@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Fleshgrinder <php@fleshgrinder.com>, php-internals <internals@lists.php.net>, 
	Ben Ramsey <ben@benramsey.com>
Content-Type: multipart/alternative; boundary="001a11460822f3316805506925d2"
Subject: Re: [PHP-DEV] [RFC] [Discussion] UUID
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11460822f3316805506925d2
Content-Type: text/plain; charset="UTF-8"

On Thu, May 25, 2017 at 5:48 PM, Marco Pivetta <ocramius@gmail.com> wrote:

> Hey Nikita,
>
> On Thu, May 25, 2017 at 12:14 PM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
>> On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder <php@fleshgrinder.com>
>> wrote:
>>
>>> On 5/24/2017 10:12 PM, Ben Ramsey wrote:
>>> > I'll take a look at the patch soon. If this is accepted to the core,
>>> > I'll probably add an adapter to ramsey/uuid that wraps this
>>> > implementation. The point of the "over engineering" there is to provide
>>> > choice. Some users want to generate bytes from sources other than
>>> > random_bytes() (i.e., libsodium) or encode UUIDs in different ways
>>> > (i.e., ordered time). A UUID generator in the core will only help to
>>> > improve ramsey/uuid, providing more choice and better performance.
>>> >
>>> > I may split out the less-used adapters and codecs into separate
>>> > components in version 4 or 5 of ramsey/uuid, though, since most users
>>> > don't need anything other than the default.
>>> >
>>> > -Ben
>>> >
>>>
>>> Yes, exactly.
>>>
>>> The provided implementation does not have any of the options your
>>> library offers. There are no special formatters, no accessors for e.g.
>>> time (not applicable to v3, v4, and v5), no RNG choices, no mutability,
>>> ... well ... nothing. It is just a straight UUID implementation.
>>>
>>> I also hope that this implementation will help to get rid of uniqid at
>>> some point.
>>>
>>> --
>>> Richard "Fleshgrinder" Fussenegger
>>>
>>
>> I'm wondering if just adding a uuid_v4_create() function (directly
>> returning a UUID string) might not cover the 95% use case here. My general
>> impression is that that's what people are usually interested in -- parsing
>> UUIDs etc. seems to be a rather niche concern.
>>
>> Nikita
>>
>
>
> I'd say that a good example of how this would change things is the
> `DateTime` object.
> How many times do you see people passing around `DateTime` objects, and
> how many times do you see *valid* (not wordpress) use-case scenarios where
> a datetime string is thrown around?
>
> That's the kind of change that a built-in type may trigger here.
>
> I had issues about this due to the squishy behavior of the reflection API
> with internal classes, but Richard covered every rough edge, as per
> discussion above.
>

A big difference between DateTime and UUID, is that DateTime has useful
behavior. Apart from unusual cases, there is no need to inspect or modify
the interior of a UUID, while DateTime operations are common and very hard
to implement if not provided by core.

Introducing a UUID class in PHP core as *just* a type safety wrapper feels
akin to adding an EmailAddress class to core. It's certainly not an
unreasonable way to handle things, but imho also not something that should
be in core. We should be providing the primitives based on which people can
implement whichever abstractions they prefer, in a simpler and more
flexible manner than we can achieve in extension code.

Especially if it would allow us to replace a 4kloc diff with one 10loc
function.

Nikita

--001a11460822f3316805506925d2--