Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99167
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.68 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <a6ea0770-9e66-3556-b0a6-d056adb3aef4@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> <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>
Date: Thu, 25 May 2017 12:14:54 +0200
Message-ID: <CAF+90c_W0rDSd=0baaWVqFYkMGycf6X32CC5JOcpkWrx=VP_ZQ@mail.gmail.com>
To: Fleshgrinder <php@fleshgrinder.com>
Cc: php-internals <internals@lists.php.net>, Ben Ramsey <ben@benramsey.com>, 
	Marco Pivetta <ocramius@gmail.com>
Content-Type: multipart/alternative; boundary="001a11449396feed820550567d3e"
Subject: Re: [PHP-DEV] [RFC] [Discussion] UUID
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11449396feed820550567d3e
Content-Type: text/plain; charset="UTF-8"

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

--001a11449396feed820550567d3e--