> On Jul 27, 2024, at 8:36 AM, Rowan Tommins [IMSoP] <[email protected]> wrote:
> On 27 July 2024 00:58:17 BST, Morgan <[email protected]> wrote:
>>
>> I'm not talking about the MD5 or SHA1 algorithms or whether they should or
>> shouldn't be used. I'm just talking about the functions themselves. md5(), md5_file(),
>> sha1(), and sha1_file(). They only exist because there wasn't the generic hash algorithm
>> extension when they were created.
>
> I understand what is being claimed (and you're not the only one claiming it), I'm
> just not convinced it's true. I think they have standalone functions for the same reason we
> added str_contains and str_starts_with - because it's convenient to have straightforward
> functions for common use cases.
>
> The hash() function is like a 60-piece set of interchangeable screwdriver heads, which only
> professionals and enthusiasts need; md5() and sha1() are like the flat-head and Phillips
> screwdrivers that everyone has in a drawer somewhere.
>
> The thing that always surprises me is that PHP *doesn't* have a standalone function for
> SHA-256, which is the only other I've ever used.
>
> To continue the analogy, we're missing a Pozidriv screwdriver, so people are misusing the
> Phillips one. The RFC is suggesting that we take away their flat-head and Phillips screwdrivers, and
> leave them with the 60-piece set, and no instructions.
>
> My suggestion is we instead give them a Pozidriv screwdriver, and write some tips on how to use
> it correctly.
I rise in support of this mindset.
Some of us like to draw inspiration from other languages, and in that vein one of the things that
makes Go such a joy to program in is the fact the Go team continues to add "convenience"
functions with every new 6 month release.
Many (all?) of the functions the Go team adds could have been written in "userland" but
they represent such common use-cases that the Go team decided to make them easy and obvious. They
even soft deprecate functions and structs that are not ideal and replace them with ones with better
names and better signatures. If Go had started with the string and array functions PHP has today
they would almost certainly replaced them by now, ~15 years into Go's tenure.
It is a shame that PHP's culture is so hostile towards adding functionality that could also be
added in userland, especially when that functionality would simplify and standardize algorithms that
are non-obvious and/or too easy to implement incorrectly. If the PHP culture embraced moving common
use-cases into core it would make PHP much more pleasurable to program in and make it much less
likely that PHP programs would have bugs and/or security vulnerabilities.
> On Jul 27, 2024, at 6:14 PM, Morgan <[email protected]> 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.
-Mike
P.S. But as we know a standardized \PHP namespace is apparently never going to happen
although for the life of me I still cannot understand why not — and I was here during the voting
down of that RFC ~4 years ago — given how so many other languages had done the equivalent.