Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99178
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c_W0rDSd=0baaWVqFYkMGycf6X32CC5JOcpkWrx=VP_ZQ@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>
Date: Thu, 25 May 2017 17:48:02 +0200
Message-ID: <CADyq6sK1p+Ruf9NT1zbAiz-QjBGT_5hitNu4J0ns6+o0Y8gFYg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Fleshgrinder <php@fleshgrinder.com>, php-internals <internals@lists.php.net>, 
	Ben Ramsey <ben@benramsey.com>
Content-Type: multipart/alternative; boundary="001a1144354c9a13ab05505b26ed"
Subject: Re: [PHP-DEV] [RFC] [Discussion] UUID
From: ocramius@gmail.com (Marco Pivetta)

--001a1144354c9a13ab05505b26ed
Content-Type: text/plain; charset="UTF-8"

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.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--001a1144354c9a13ab05505b26ed--