I agree - "it's harder to imagine a scenario in real life where".
From php perspective, swapping parameters in inheritance SHOULD NOT be
allowed, as without named parameters the parameters are not swapped.
Also, if the parameters are typed differently, the example is even
impossible (and nowdays, typed parameters are very common, thus
"commonly impossible").
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?
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 28 Oct 2020 15:57, Rowan Tommins wrote:
On 28/10/2020 10:45, Michael Voříšek - ČVUT FEL wrote:
https://3v4l.org/X8omS parameters renamed, result with named parameters
is different
While it's easy to construct an example where this happens, it's harder to
imagine a scenario in real life where:
* a sub-class overloads the function with different parameter names...
* ...that overlap with the original parameter names... (i.e. the call will
succeed)
* ... but not in the same order...
* ...where calling with ordered parameters results in the expected behaviour
(i.e. it's not already incorrect code)
It seems more likely in practice that a polymorphic call assuming the
parameters are in the same order would fail where one assuming they have the
same names will succeed, e.g.:
class A {
public function search(string $needle, string $haystack) { ... }
}
class B extends A {
public function search(string $haystack, string $needle) { ... }
}
$aOrB->search("foo", "foobar"); // incorrect call on instances of B, but
allowed in every version of PHP
$aOrB->search(needle: "foo", haystack: "foobar"); // correct behaviour whether
instance of A or B :)
https://3v4l.org/kgHWf renamed parameter, call with named parameters
does not succeed at all (which violated basic principe of OOP
inheritance at least)
This is the case that is explicitly discussed in the RFC:
https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance
I'm not sure what more can be said than appears in that summary, and in the
linked discussion of rejected alternatives. As the RFC says, the pragmatic
decision was taken to defer these errors to runtime.
It's worth noting that since PHP doesn't have checked exceptions, a child
method throwing an error that it's parent wouldn't is already possible and not
considered a violation: https://3v4l.org/3m7eo
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
