On Wed, May 6, 2020 at 2:34 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On 5 May 2020 09:42:19 BST, Arvids Godjuks <arvids.godj...@gmail.com> > wrote: > >So in my opinion, a better replacement for uniqid is needed - have it > >generate a bigger string with more entropy and better underline algorithm, > >but it being time-based should be a thing stiff. And do not call it a > >"random_string" or something, cause it's not that :) > > > A question just got posted on Stack Overflow asking for pretty much > exactly what we've been discussing: > https://stackoverflow.com/q/61634022/157957 > > You're right that the requirements for "random" and "unique" are distinct. > Perhaps what we need is a unique_string function that allows you to specify > the format (length and some control over allowed characters) and uses a mix > of randomness and time (perhaps using the same time source as hrtime()?). > > Then uniqid() could be deprecated, and anyone relying on its exact format > could write a polyfill, while people wanting other formats wouldn't need to > mess around with binhex, hexdec, etc. > A possible candidate for this would be ULID (https://github.com/ulid/spec), which is basically timestamp + random + base32 encoding. The timestamp part makes ULIDs approximately lexicographically orderable, the random part makes sure things are unique when generated in parallel and the base32 encoding avoids people having to deal with raw binary data. Regards, Nikita
