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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
