On 20/06/2023 07:26, Nicolas Grekas wrote:
Then, among both options, we need to select the one with the best future
proofness, and that's definitely the OOP one to me, because it comes with
more guarantees (type checks).

So are you saying we should deprecate the function-based version completely, and not provide any new names at all? I think I would prefer that to the confusing set of aliases the current RFC text proposes.

I think I would support any of these options:

1) Do nothing. I don't see the current situation as being that big a problem. 2) Deprecate the function-based signature, provide no alternative but to switch to the interface-based one. Potentially non-trivial upgrade for those affected, but leaves us with a single clear function. 3) Create new names for both signatures, treating neither of them as more "default" than the other, so that users have a clear choice between the two. Deprecate the existing function completely.

All the other suggestions seem likely to create a lot of confusion, and not actually leave us much better off in the long term.


Rowan Tommins

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to