Re: [RFC] [Discussion] Deprecate functions with overloaded signatures

From: Date: Thu, 15 Jun 2023 15:05:57 +0000
Subject: Re: [RFC] [Discussion] Deprecate functions with overloaded signatures
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-120590@lists.php.net to get a copy of this message
On 27-4-2023 23:28, Máté Kocsis wrote:
Hi Internals, As you have possibly already experienced, overloaded signatures cause various smaller and bigger issues, while the concept is not natively supported by PHP. That's why I drafted an RFC which intends to phase out the majority of overloaded function/method signatures and also forbid the introduction of such functions in the future: https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures I'm not sure at all what the best solution would be to get rid of the overloaded FFI methods, so I hope that someone comes up with a better idea. Currently, the RFC suggests deprecating and then removing the static methods in question, but I hope that we can find a more elegant approach. So this section is incomplete and it's just for starting the discussion. Regards, Máté
The impact analysis on userland code seems to be missing for some of the proposals, most notably for the proposals which I expect will have the highest impact. I'd like to ask for an impact analysis to be added to each of these: * array_keys() * ReflectionProperty::setValue() For the get*_class() deprecation, I wonder if an additional impact analysis is needed for packages which may not have removed usages of get_class( null ), which would now be double-impacted (and not caught by the current analysis). Smile, Juliette

« previous php.internals (#120590) next »