Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120150
Message-ID: <ffa8138a-f1b6-3926-bc2f-558ffca344b0@gmail.com>
Date: Fri, 28 Apr 2023 09:16:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
To: internals@lists.php.net
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: rowan.collins@gmail.com (Rowan Tommins)

On 27/04/2023 22:28, Máté Kocsis wrote:
> 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


Hi Máté,

While I broadly agree with the sentiment behind this, I think the 
upgrade path needs to be examined a bit more closely.

As Kamil says, a potential 1-year deprecation is probably not enough, 
and we need to keep in mind that many libraries and applications need to 
support multiple versions of PHP at once. If they are to become errors 
in 9.0, there should be some way to write code that will run on both 8.0 
and 9.0.

The only ones in this list I can see that being easy for are 
assert_options (you can write a polyfill for the new assert_set_option, 
and switch all code to use that), and get_class() / get_parent_class() 
(you can start passing $this right away).

A lot of the others introduce new methods, which can't easily 
polyfilled, or directly change the signature. For all of those, users 
would have to write an additional wrapper, with explicit detection of 
the PHP version to make the call in one form or the other.


I have particular concerns about session_set_save_handler. The impact is 
hard to estimate, because it will be used directly in applications more 
often than in libraries. The multiple parameter signature is much older, 
dating back to PHP 4, with the object form added only in PHP 5.4. That 
may seem a long time ago, but there is currently no incentive to change 
existing code between the styles, and doing so requires a reasonable 
amount of work.


On a different point, I think "assert_options" is a peculiar name for 
either setting or getting a single option, and would suggest it be 
replaced with two new functions, assert_get_option and 
assert_set_option. Replacing both variants also makes it easier for 
users to find everywhere they've used it, and polyfill both variants, 
rather than having to examine each.


Regards,

-- 
Rowan Tommins
[IMSoP]