Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110073
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> <CA+kxMuS5DcHd18Nq5eXCOZB24KUsydtq4tg+wXgTuPORO+XMrA@mail.gmail.com>
 <CALKiJKqwNXgYY3rc+wZqnuwtcq+WmAe8VjUvcuY1sFAvAJrEAQ@mail.gmail.com>
 <CA+kxMuQ6Gaua-Ozk21KT2p8GWRhbkiQFZwYi+L22n5xq7S2ggQ@mail.gmail.com> <456FDEDB-770E-41A0-9B15-46768232F2C2@benramsey.com>
In-Reply-To: <456FDEDB-770E-41A0-9B15-46768232F2C2@benramsey.com>
Date: Thu, 7 May 2020 18:14:14 +0200
Message-ID: <CAL0xaBET336+waUCxnY0XLcQf2Js0K6G2ZUQekzaXu+Z3N-VFg@mail.gmail.com>
To: Ben Ramsey <ben@benramsey.com>
Cc: Dan Ackroyd <Danack@basereality.com>, Rowan Tommins <rowan.collins@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000098aacd05a5112df3"
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000098aacd05a5112df3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Ben,

On Thu, 7 May 2020 at 17:29, Ben Ramsey <ben@benramsey.com> wrote:

> > On May 7, 2020, at 09:33, Dan Ackroyd <Danack@basereality.com> wrote:
>
> *snip*
>
> I=E2=80=99m done waxing philosophical, so what I can say about `uniqid()`=
?
>
> This is one of those functions I think (without doing the research) is
> used a lot in CLI scripts and tooling. As a result, it may be impossible =
to
> do good research on this, since these scripts are probably not available =
in
> public repositories. Additionally, when I write scripts like this, I don=
=E2=80=99t
> reach out for Composer packages, since I don=E2=80=99t need the overhead =
of a
> full-blown project or library, and I doubt others do, as well. This means
> allowing userland to fill the void left by the removal of `uniqid()` may
> not be a good option.


> I think we should err on the side of BC with `uniqid()`. While the manual
> says it=E2=80=99s been in the language since PHP 4, the research I did in=
 the
> =E2=80=9Cmuseum=E2=80=9D shows that it=E2=80=99s been in PHP since 2.0b9 =
(see the Changelog in the
> tarball for 2.0b10[6]).
>
> Is there any way we can improve this function without deprecating/removin=
g
> it?
>

Exactly my case - a background processing script that lives in CLI without
any 3rd party libraries parsing a CSV just doing some SQL queries inserting
data and using uniqid(more_entropy=3Dtrue) (and removing the dot from it's
output).

In my opinion, this is one of those somewhat simple and widely used
functions that do not need constant updating and just making it's random
part more robust and up to date will be sufficient for it's use. Yes, we
can depreciate the uniqid and replace it with a new function that is much
better at its job to facilitate proper migration. But removing a tool like
this from the core does seem somewhat on the extreme end of things.

--=20
Arv=C4=ABds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

--00000000000098aacd05a5112df3--