Hey Nikita, On Thu, May 25, 2017 at 12:14 PM, Nikita Popov <nikita....@gmail.com> wrote:
> On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder <p...@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/
