Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124671
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
In-Reply-To: <c51d4933-15e2-4525-853f-fc41d7865139@varteg.nz>
Date: Mon, 29 Jul 2024 00:11:54 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <62608356-9A91-48AD-BAE8-9BED233BB715@newclarity.net>
References: <USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
 <1a88918e-e808-d778-45e1-53797660e093@php.net>
 <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
 <c03eb187-bd21-4a4b-9faf-8d0243eaa994@varteg.nz>
 <aa6bc7aa-28d9-40ca-974f-65075adb6199@rwec.co.uk>
 <3563cf9b-8eab-4c82-b525-a5d2f9a767bb@varteg.nz>
 <38920A4B-790D-48C7-B2F6-C49D3F506232@rwec.co.uk>
 <951AA94A-8C07-446E-925C-15BB97F146A4@newclarity.net>
 <c51d4933-15e2-4525-853f-fc41d7865139@varteg.nz>
To: Morgan <Weedpacket@varteg.nz>
From: mike@newclarity.net (Mike Schinkel)


> On Jul 28, 2024, at 9:19 PM, Morgan <Weedpacket@varteg.nz> wrote:
> I, too, wish there was more willingness to add useful functions to =
core.=20

:-)

>>> On Jul 27, 2024, at 6:14 PM, Morgan <weedpacket@varteg.nz> wrote:
>>> Why a SHA2 algorithm? Why not a SHA3 one? How about standalone =
functions for both, and then when SHA4 comes along (as it inevitably =
will) another standalone function for one of its variants?
>> Yes. Yes, And Yes.
>> And ideally within a `\PHP` namespace.
> At that point you've got \PHP\sha3() instead of hash("sha3-?"), and =
now you've (a) lost the word "hash" indicator of what's going on, and =
(b) hidden the choice of "?" from the user. I'm not really seeing an =
improvement.

Well, your comments are based on assumptions that they would have to be =
implemented as you were envisioning when you wrote your reply.=20

My "Yes. Yes. And Yes" was not intended to be full RFC that fleshed out =
all the considerations and proposed a specific implementation. IOW, =
there are definitely ways to address your criticisms if we are =
open-minded in what could be considered. :-)

> At that point you've got \PHP\sha3()=20

I'm sure you will find it ironic in hindsight like I do that you chose =
`sha3` (vs. `md5`) as the function to illustrate your argument about not =
having the word "hash" given how SHA is an acronym for "Secure Hash =
Algorithm."  :-)

By the same token, we could complain about how parse_url(), urlencode() =
and urldecode() all lost the word "resource." :-o

Seriously though, some acronyms are well-known enough =E2=80=94 or =
easily discovered enough =E2=80=94 that we should be able to use them as =
function names without lamenting they are not spelled out.

But if the concern is they are not grouped together as hashing functions =
than =E2=80=94 had we had a `\PHP` namespace as an option =E2=80=94 we =
could easily have:=20

- \PHP\Hashing\md5()
- \PHP\Hashing\sha1()
- \PHP\Hashing\sha256()
- \PHP\Hashing\sha3()
- etc.

Also, there is no reason we have to be exhaustive. The pareto principle =
is always one we should consider when deciding when anything should be =
elevated to having its own dedicated function.

> instead of hash("sha3-?")

The problem here is semantic information is encoded in a string rather =
than in a named symbol and thus is not recognized in the AST when =
parsing and requires a hack of diving into the string in order to =
validate.=20

So typically, no type checking, no auto-complete, and potentially =
delayed error detection.

Using strings where symbols would be better is a common wart in PHP =E2=80=
=94 such as PHP not having a first-class type for class, interface or =
function =E2=80=94 so we have to pass around names as non-typesafe =
strings instead. =20

BTW, I asked ChatGPT to opine on the problems caused with =
strings-as-symbols from computer science and software engineering =
perspectives, and this is what it gave me:

https://chatgpt.com/share/17d57881-c411-4b64-863a-d0692b4a4577=20

> and (b) hidden the choice of "?" from the user. I'm not really seeing =
an improvement.

What's wrong with something like?

use PHP\Hashing\sha3;
use PHP\Bits;=20
...
$hash_224 =3D  sha3($data,Bits::224);
$hash_256 =3D  sha3($data,Bits::256);
$hash_384 =3D  sha3($data,Bits::384);
$hash_512 =3D  sha3($data,Bits::512);

The point I am trying to get across is that improving the developer =
experience is not a binary true or false endeavor. There are many ways =
to improve DX, but they all must start with a openness to consider doing =
it.

> On Jul 28, 2024, at 9:19 PM, Morgan <weedpacket@varteg.nz> wrote:
>=20
> Hey, all I'm doing is pointing out that the only reason those =
functions were standalone to start with is because when they were added =
they were the only ones around; they weren't introduced as "easier to =
use" alternatives to the more generic case. If hash() had been added in =
PHP with half a dozen different algorithms right at the beginning, would =
md5() and sha1() have been given special treatment? Possibly: MD5 (and =
later SHA1) got all the publicity at the time.
>=20
> I haven't seen an explanation of what makes them "easier to use": if =
you want to use md5() (for whatever reason: I don't care) it's not that =
hard to write hash("md5") instead. I just went through a file =
deduplication utility of mine and did exactly that. Yes, I am using MD5 =
as a message digest algorithm.

But just because they were historical artifacts doesn't mean that they =
should be frowned on, or removed. `echo` is also a historical artifact, =
but no one is arguing we should get rid of this:

echo "Hello World";

And then require developers to use this instead:

fprintf(STDOUT, "Hello World");=20

=C2=AF\_(=E3=83=84)_/=C2=AF

-Mike