Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110072
Message-ID: <456FDEDB-770E-41A0-9B15-46768232F2C2@benramsey.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_7E4AA846-4E63-4496-8324-83FC36AC15D6";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 7 May 2020 10:28:53 -0500
In-Reply-To: <CA+kxMuQ6Gaua-Ozk21KT2p8GWRhbkiQFZwYi+L22n5xq7S2ggQ@mail.gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
To: Dan Ackroyd <Danack@basereality.com>
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>
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail=_7E4AA846-4E63-4496-8324-83FC36AC15D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On May 7, 2020, at 09:33, Dan Ackroyd <Danack@basereality.com> wrote:
>=20
> On Thu, 7 May 2020 at 10:13, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>>=20
>> Unless we're actively trying to shrink the functionality of PHP's =
core,
>=20
> I think we should.
>=20
> There are things that were added to core rather than done in userland =
because:
>=20
> * distributing libraries in userland used to be a lot harder than it =
is now.
>=20
> * Some stuff needed to be in core to give adequate performance. As
> userland PHP has had it's relative performance increased, and also
> computers have gotten a little faster since the project began*, that
> need has been greatly reduced.
>=20
> So although the choice to provide some functionality in core was the
> correct choice at the time, it would not be a correct choice to do
> now.
>=20
> The reason to try to reduce the amount of core code is that
> maintaining core code is much more difficult than maintaining userland
> libraries.
>=20
> There are swathes of PHP core that are scary to fix bugs in, let alone
> think about adding new features or refactoring their API.
>=20
> Although each removal would need to be justified individually, I think
> as a general aim 'more userland, less core' is good.


In many ways, I agree. In other ways, I see things like `array_column()` =
and `str_contains()`[1] as being obvious additions to the core, since =
they=E2=80=99re implemented in userland so often. However, we recently =
rejected the Server-side Request and Response Objects RFC[2], so what is =
the over-arching philosophy that drives our decisions?

I don=E2=80=99t know the answer to this, but I think it might be a good =
exercise to consider it. It=E2=80=99s probably different for each person =
here. I think Paul Jones attempted to call attention to this in the =
_epilogue_ to the =E2=80=9CServer-side Request and Response Objects=E2=80=9D=
 vote[3]:

> The initial impression is that there is a strong desire for work
> that can be done in userland to stay in userland. However, that
> impression conflicts with the recent acceptance of str_contains(),
> which is very easily done in userland.
>
> **Lesson:** Of functionality that can be accomplished in userland,
> only trivial/simple functionality is acceptable.

I reject the conclusion (=E2=80=9Clesson=E2=80=9D) here, but it=E2=80=99s =
difficult not to arrive at this conclusion based on the observations. It =
might be interesting to flip this around, though, in the case of the =
request/response objects vote. Maybe this specific lesson could be =
better stated as:

> **Lesson:** Of functionality that can be accomplished in userland,
> functionality viewed as having a high maintenance overhead is best
> left in userland.

I don=E2=80=99t know whether that=E2=80=99s the correct lesson, either, =
but I think it helps illustrate that we=E2=80=99re all approaching these =
decisions from our own philosophical points of view for what should or =
shouldn=E2=80=99t be PHP, and what appears to be the guiding =
principle(s) to one may be the opposite (flipped) to another.

So, where am I going with this?

I really have no idea. I thought I had a point about trying to =
articulate some overarching philosophy for the direction of PHP, but now =
that I=E2=80=99ve gotten here, I think I=E2=80=99ve convinced myself =
that one of PHP=E2=80=99s strengths is that it has no guiding =
philosophy. Each person here brings with them their own philosophies of =
how the language should be shaped, and even those philosophies may =
change and contradict themselves from time-to-time, and that=E2=80=99s =
what=E2=80=99s made the language what it is today, and perhaps that=E2=80=99=
s what continues to make the language better.

While it would be nice to understand the rationale behind decisions for =
what goes into core and what comes out, the reality is people are making =
these decisions and we don=E2=80=99t get things right all of the time, =
but we do get things right much of the time. I think =E2=80=9CAllow =
trailing comma in parameter list[4]=E2=80=9D and =E2=80=9CAdd =
str_starts_with() and str_ends_with() functions[5]=E2=80=9D might be =
good examples of this.

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/removing it?

Cheers,
Ben


[1]: https://wiki.php.net/rfc/str_contains
[2]: https://wiki.php.net/rfc/request_response
[3]: https://externals.io/message/109563
[4]: https://wiki.php.net/rfc/trailing_comma_in_parameter_list
[5]: =
https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions
[6]: https://museum.php.net/php2/php-2.0b10.tar.gz

--Apple-Mail=_7E4AA846-4E63-4496-8324-83FC36AC15D6
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCXrQpNQAKCRCwLZeYnIwH
G73DAP9mi3rf6wLWGQCMqGMI9NwzaKc1u+2q9ZCYDQziNrbWDgD6A/h7MgSFAloo
nbldFhBKQOxO/iC/mMClWFut1ZTyRPw=
=xz6R
-----END PGP SIGNATURE-----

--Apple-Mail=_7E4AA846-4E63-4496-8324-83FC36AC15D6--