Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110043
MIME-Version: 1.0
References: <9e3b1604-8d0a-9db4-aab6-e5f2198252f4@allenjb.me.uk>
 <C4580849-BC5B-45CA-9B57-56CB63B3F8F0@benramsey.com> <3a2924d2-31b9-fee5-5548-49c889eca2f4@heigl.org>
 <CALKiJKoXfW2usFmHS2ev2ihe6i=SV5JQaMgQmHCi5-rqeEdOWw@mail.gmail.com>
 <CANUQDCi3+fzy9E9kJ-vuDsTXMwNko9PpBUBAGUTxacdaQFPE5g@mail.gmail.com>
 <CAJvSBVMGEyqKNOxtGLyVqKrc0YRpiTyc8Ok55cocSS-2trL=Xw@mail.gmail.com>
 <CALKiJKpTf3AyhLjbMOu+gO--gmgatZ0Nazbsj2AZ-L2PVvOe5w@mail.gmail.com>
 <CAL0xaBG-VLN6pMPoKttkCZLXdzOKJLo0mdZvL2ggOy1Fqjae8w@mail.gmail.com> <D21D4456-228B-4059-9B51-F40B3EC94286@gmail.com>
In-Reply-To: <D21D4456-228B-4059-9B51-F40B3EC94286@gmail.com>
Date: Wed, 6 May 2020 14:44:22 +0200
Message-ID: <CAF+90c8LkMOQXGDqDhyOEr8SjUyy+omdBczGXqJp6SNa0yezrA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000097850b05a4fa2001"
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000097850b05a4fa2001
Content-Type: text/plain; charset="UTF-8"

On Wed, May 6, 2020 at 2:34 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 5 May 2020 09:42:19 BST, Arvids Godjuks <arvids.godjuks@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

--00000000000097850b05a4fa2001--