Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112132
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_40ef0e8576a4b1f297cd639a2b30221e"
Date: Wed, 28 Oct 2020 16:14:59 +0100
To: internals@lists.php.net
In-Reply-To: <73716a39-53ac-c9b4-a38a-86922a2edeb2@gmail.com>
References: <a644ec10ee384cc2b2655c75bbd66904eef1f609a71a88953346c7557ee2c93c@mahalux.com>
 <c129c01c-2c8a-4328-8cbb-da04ae9400c5@gmail.com> <893315378549048c16f2dc212bdec698fe32f8d10d37f9c5f74ffd179a1e0de9@mahalux.com>
 <73716a39-53ac-c9b4-a38a-86922a2edeb2@gmail.com>
Message-ID: <275e0bd6800960e9f73f240cb95a6c5ae5059f3212285bf75a473260c0bce35f@mahalux.com>
Subject: Re: [PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does
 not throw
From: vorismi3@fel.cvut.cz (=?UTF-8?Q?Michael_Vo=C5=99=C3=AD=C5=A1ek_-_=C4=8CVUT_FEL?=)

--=_40ef0e8576a4b1f297cd639a2b30221e
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8; format=flowed

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]
--=_40ef0e8576a4b1f297cd639a2b30221e--