Re: Bug #80248 - Swapping parameter names during inheritance does not throw

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]