Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110001
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>
In-Reply-To: <CALKiJKpTf3AyhLjbMOu+gO--gmgatZ0Nazbsj2AZ-L2PVvOe5w@mail.gmail.com>
Date: Tue, 5 May 2020 10:42:19 +0200
Message-ID: <CAL0xaBG-VLN6pMPoKttkCZLXdzOKJLo0mdZvL2ggOy1Fqjae8w@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b4e38805a4e2a101"
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000b4e38805a4e2a101
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 5 May 2020 at 10:26, Rowan Tommins <rowan.collins@gmail.com> wrote:

> On Tue, 5 May 2020 at 08:52, Peter Bowyer <phpmailinglists@gmail.com>
> wrote:
>
> >
> > On Tue, 5 May 2020 at 07:38, Niklas Keller <me@kelunik.com> wrote:
> >
> >> Rowan Tommins <rowan.collins@gmail.com> schrieb am Mo., 4. Mai 2020,
> >> 10:59:
> >> > Although the name sounds similar, I don't think UUID would be a good
> >> > replacement for uniqid(). In my experience, it's used for things lik=
e
> >> > generating ID attributes for HTML elements, or suffixes for table
> >> names, or
> >> > even file names; applications that really just need a few alphanumer=
ic
> >> > characters that are different each time.
> >>
> >> Seems like UUIDs would be a good fit for all of these.
> >>
> >
> > For file names, absolutely. In many cases they have to be unique across
> > all processes, and that's important. For the others I say a UUID is onl=
y
> a
> > good replacement if taking a substring of a UUID is going to be unique.
> >
>
>
> As well as being nearly 3 times as long as the current uniqid() output, a
> UUID is generally formatted with hyphens, which may be disallowed or
> require careful quoting in various contexts. If you have to strip those
> out, or otherwise manipulate the result to fit the use case, you've faile=
d
> at the original aim of having a single function that doesn't need further
> processing. (Leaving aside the fact that we don't actually have any UUID
> functions in core.)
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

The same notion here. UUID's and random_bytes sometimes are overkill, too
slow or you can just exhaust the random source.
I have a use-case where I needed exactly the way uniqid worked (with
more_entropy =3D true) - a serial incrementing random value that I needed t=
o
create for 20-30 thousand items in one request. It was fast, efficient and
there was absolutely no need to have a truly random value. And it needed to
be human-readable easily because it was also sent via SMS in some cases.

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 :)

Thanks!


--=20
Arv=C4=ABds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

--000000000000b4e38805a4e2a101--