Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99203
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: <CAF+90c9y0e+BsSSmLWJ3KHMfK0EvPEJ5ppDAnmqMzjahL0UjBw@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> <CAF+90c9y0e+BsSSmLWJ3KHMfK0EvPEJ5ppDAnmqMzjahL0UjBw@mail.gmail.com>
Date: Fri, 26 May 2017 15:26:35 +0200
Message-ID: <CADyq6s+Qa1NWxvzON6m2v7EoK0LW7UY1Og6-aOsqeUscjOe-Sg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Ben Ramsey <ben@benramsey.com>, Fleshgrinder <php@fleshgrinder.com>, 
	php-internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a114b700e72b64905506d497d"
Subject: Re: [PHP-DEV] [RFC] [Discussion] UUID
From: ocramius@gmail.com (Marco Pivetta)

--001a114b700e72b64905506d497d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On 26 May 2017 10:30 a.m., "Nikita Popov" <nikita.ppv@gmail.com> wrote:

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 provi=
de
>>> > 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 gener=
al
>> impression is that that's what people are usually interested in -- parsi=
ng
>> 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 wher=
e
> 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.


Very true, but we're also talking about standardised values that everyone
in userland keep doing wrong in some way. If EmailAddress does ever make it
into core, that's just added value.
Types over string checks all the way =F0=9F=91=8C

Especially if it would allow us to replace a 4kloc diff with one 10loc
function.


Agreed: this would be much simpler if the class definition didn't have all
the possible quirks of manually- and C-level defined classes. The fact that
Richard had to test stuff like order of parameters, reflection, etc is,
frankly, frustrating.

Any hope for having the same stubbing of internal classes that HHVM had?
Sara?  =F0=9F=98=8B

--001a114b700e72b64905506d497d--