Significant additional code in the engine to perform additional checks and/or name aliasing
I know, but we can do very easily one thing - check and throw if
overriding method has one or more named parameter on different position.
On class creation time, ie. only once, no overhead per call.
Then calling with named/unnamed parameters is **consistent** (or
resolves to an "Unknown named parameter" error) and... We are safe!
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 28 Oct 2020 17:43, Rowan Tommins wrote:
On 28/10/2020 15:14, Michael Voříšek - ČVUT FEL wrote:
I agree - "it's harder to imagine a scenario in real life where".
[...]
If we can agree, that implementation is not guaranteed to be called with
named parameters only, what real world usecase to defend this current
php behaviour is left?
You're thinking about this the wrong way around: the simplest implementation is
to detect non-existent named parameters (which happens to include renamed
parameters) at run-time; it is additional checks on top of that which need to
be justified.
Other approaches to the problem require at least one of:
* Significant additional code in the engine to perform additional checks and/or
name aliasing
* Users to change existing code which works correctly, but would theoretically
break if used with named parameters
The advantages are almost entirely theoretical, with few realistic examples.
So the "pragmatic approach" the RFC refers to concludes that the benefit of
additional analysis does not outweigh its cost.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
