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

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]