Re: Deprecating uniqid()
| From: | Rowan Tommins | Date: | Wed, 06 May 2020 12:33:48 +0000 |
| Subject: | Re: Deprecating uniqid() | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-110040@lists.php.net to get a copy of this message | ||
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.
Regards,
--
Rowan Tommins
[IMSoP]