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