Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120590
To: internals@lists.php.net
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
Message-ID: <648B28D5.1060506@adviesenzo.nl>
Date: Thu, 15 Jun 2023 17:05:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------010604000206060104090203"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------010604000206060104090203
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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

--------------010604000206060104090203--