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
