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