Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112133 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 9916 invoked from network); 28 Oct 2020 17:20:32 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Oct 2020 17:20:32 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 69AB0180508 for ; Wed, 28 Oct 2020 09:39:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 28 Oct 2020 09:39:25 -0700 (PDT) Received: by mail-ua1-f48.google.com with SMTP id x26so1710427uau.0 for ; Wed, 28 Oct 2020 09:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+ow5geWjgUhs4waHt694LXevrRYFLG/RYllwYJQ/HL4=; b=KdxSxX8dh59emGQSzcukXE/Oy+QudaVSecAymEmL+/LpbsuZoIobw+CBexz2rfXZuv 5Dx91qIrU6XmaLYhLBQIZK4sHTsLseAfSfc0kl3LAqE1oCkHFNEMe2YWHJY0q0rXnVz8 HdZ39YHg7BB0zn2EaYNaeCdD3Mxco+14UEwWQkzsJuqIjm1LESsUl4gmcgyCWa7tOT6l 1PruEA8/JRNKdPiHXcpDb0tLnUvRBuh+F6NHtOEMzQuUkKBsXhkAKB9fj/+f1hODSzUI lz7tjnauAJpb75EcjHATQggRU9Og6ABF290Y7YFOrfNTtPiBp8Gqy8fThQkfuFWueQNd nVBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+ow5geWjgUhs4waHt694LXevrRYFLG/RYllwYJQ/HL4=; b=jjQ3C5ytp0Nl/YM2zTIKg2qvcv/ANrC8Utv0NT4wo53qwsSkuZVDNTKrFCwXUatjVD NArBFkofZeASSgR6BVDQjlesit1/tAlZlgDAPT8rP2EWbcyQIaphUBSgb/k1SvmWuoDC 1IE0TJyeSxtak1K8QXMAuL+p1DXihryEhkl5dVXQu5PPDKG+nXAIdgzaap9yz/mIPViN hT5m2BpomYmbgha0A1Xr9k7HLWl5hvlOHb1uRrNprAmsIQiXp6elv+g1c69LbHhY8kpG zkCzDxw+QMt0cdnOZ3JnmzMqyQrNPVfkdqL3x9AmFJSZRsC3qBUZ8TITyy/9KM3cSRLj dESg== X-Gm-Message-State: AOAM533ZD8PGYDoQY/o3woWNGTJJ0WVwJQF+kTJGcnQsNeVn5Lnj+neK X646A1PFt6eJjsvw5vK1/+oqlM3PgO4zNqkOX4s= X-Google-Smtp-Source: ABdhPJywOFW7DdSOj2QpuyzqnWWPNFvaBa29j0Db5y+7riHS8FXmi4gyUKxiWjeLEoppNYhTMsm+Cvg1AkX9S2fJuMQ= X-Received: by 2002:ab0:2483:: with SMTP id i3mr244422uan.33.1603903164833; Wed, 28 Oct 2020 09:39:24 -0700 (PDT) MIME-Version: 1.0 References: <893315378549048c16f2dc212bdec698fe32f8d10d37f9c5f74ffd179a1e0de9@mahalux.com> <73716a39-53ac-c9b4-a38a-86922a2edeb2@gmail.com> <275e0bd6800960e9f73f240cb95a6c5ae5059f3212285bf75a473260c0bce35f@mahalux.com> In-Reply-To: <275e0bd6800960e9f73f240cb95a6c5ae5059f3212285bf75a473260c0bce35f@mahalux.com> Date: Wed, 28 Oct 2020 12:39:13 -0400 Message-ID: To: =?UTF-8?B?TWljaGFlbCBWb8WZw63FoWVrIC0gxIxWVVQgRkVM?= Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000064e3f305b2bdce0a" Subject: Re: [PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does not throw From: chasepeeler@gmail.com (Chase Peeler) --00000000000064e3f305b2bdce0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 28, 2020 at 11:15 AM Michael Vo=C5=99=C3=AD=C5=A1ek - =C4=8CVUT= FEL < vorismi3@fel.cvut.cz> wrote: > 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"). > > What do you mean they "aren't swapped?" class A { public function foo ($str1,$str2){ return strcompare($str1,$str2); } } class B extends A{ public function foo($str2,$str1){ return strcompare($str2,$str); //or //return parent::foo($str1,$str2); } } They are swapped in the above example because the code inside B::foo handles the swapping. And, maybe there is a valid reason that the developer wanted to emphasize $str2 over $str1 in the subclass. 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=C3=BC=C3=9Fen / S p=C5=99=C3=A1tels= k=C3=BDm pozdravem, > > Considering that parameter swapping prior to unnamed parameters has always been supported, what unique issue does it represent that requires we solve it now? Anything done to prevent it would almost certainly be a huge BC break. As for real world use-cases, I can think of a few: 1.) Developer the subclass wants to make certain parameters optional which weren't originally at the end of the parameter list 2.) Parent class broke common practices in terms of parameter order ($needle, $haystack vs $haystack, $needle) and they want their subclass to follow the more commonly used pattern. 3.) The developer of the subclass just wants them in a different order for some reason that makes sense to them. Maybe they don't need to support polymorphism. Maybe the idea is that the subclass will be used INSTEAD of the parent class and any knowledge of the parent class by other programmers isn't even necessary. > Michael Vo=C5=99=C3=AD=C5=A1ek > > On 28 Oct 2020 15:57, Rowan Tommins wrote: > > > On 28/10/2020 10:45, Michael Vo=C5=99=C3=AD=C5=A1ek - =C4=8CVUT FEL wro= te: > > > >> https://3v4l.org/X8omS parameters renamed, result with named parameter= s > >> 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, bu= t > allowed in every version of PHP > > > > $aOrB->search(needle: "foo", haystack: "foobar"); // correct behaviour > whether instance of A or B :) > > > I agree that this scenario is very contrived. You are looking at a scenario where multiple examples of poor programming are layered on top of each other. Trying to prevent such scenarios risks going down a rabbit hole that removes a lot of freedom from the language. > >> 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_inher= itance > > > > 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=C3=A9 Collins) > > [IMSoP] --=20 Chase Peeler chasepeeler@gmail.com --00000000000064e3f305b2bdce0a--