> On Jul 28, 2024, at 9:19 PM, Morgan <weedpac...@varteg.nz> wrote:
> I, too, wish there was more willingness to add useful functions to core.
:-)
>>> On Jul 27, 2024, at 6:14 PM, Morgan <weedpac...@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.
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()
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 — or easily discovered
enough — 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 —
had we had a `\PHP` namespace as an option — we could easily have:
- \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.
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 — such as
PHP not having a first-class type for class, interface or function — so we have
to pass around names as non-typesafe strings instead.
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
> 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;
...
$hash_224 = sha3($data,Bits::224);
$hash_256 = sha3($data,Bits::256);
$hash_384 = sha3($data,Bits::384);
$hash_512 = 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 <weedpac...@varteg.nz> wrote:
>
> 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.
>
> 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");
¯\_(ツ)_/¯
-Mike
