Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124669
Message-ID: <c51d4933-15e2-4525-853f-fc41d7865139@varteg.nz>
Date: Mon, 29 Jul 2024 13:19:23 +1200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: Mike Schinkel <mike@newclarity.net>,
 "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: PHP internals <internals@lists.php.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>
Content-Language: en-GB
In-Reply-To: <951AA94A-8C07-446E-925C-15BB97F146A4@newclarity.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: weedpacket@varteg.nz (Morgan)

On 2024-07-28 15:54, Mike Schinkel wrote:

> 
> 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.
> 
I, too, wish there was more willingness to add useful functions to core. 
Just saying "they can be implemented in userland" is a bit of a cop-out 
because, duh, PHP is Turing-complete. A lot of the existing array 
functions could be replicated by userland (ab)use of array_reduce, and 
yet no-one would suggest removing them, and if they'd been absent a lot 
of people would be asking for them.

Anyone else wish that sort() took its argument by value instead of by 
reference? (Solvable in userland.) Or how about a named argument that 
allowed you to provide a key function to sort on instead of a 
comparator? (Solvable in userland.) Okay, the first change would break a 
lot, but an alternate sorted() function that did behave that way could 
be added.


>> 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.