Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112137 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 17440 invoked from network); 28 Oct 2020 17:57:27 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Oct 2020 17:57:27 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A24D71804B3 for ; Wed, 28 Oct 2020 10:16:25 -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=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-mahalux.mvorisek.com (mail-mahalux.mvorisek.com [77.93.195.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 28 Oct 2020 10:16:25 -0700 (PDT) Received: from cd6537e88991 (10.228.0.224) by mail-mahalux.mvorisek.com (10.228.0.4) with Microsoft SMTP Server (TLS); Wed, 28 Oct 2020 18:16:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_3853c6ee407d5e136e1b25c27ff34fad" Date: Wed, 28 Oct 2020 18:16:23 +0100 To: internals@lists.php.net In-Reply-To: <5e6301c6-5ee0-5c9f-eee8-4d40fbb0276c@gmail.com> References: <893315378549048c16f2dc212bdec698fe32f8d10d37f9c5f74ffd179a1e0de9@mahalux.com> <73716a39-53ac-c9b4-a38a-86922a2edeb2@gmail.com> <275e0bd6800960e9f73f240cb95a6c5ae5059f3212285bf75a473260c0bce35f@mahalux.com> <5e6301c6-5ee0-5c9f-eee8-4d40fbb0276c@gmail.com> Message-ID: X-Mailer: SAP NetWeaver 7.03 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?=) --=_3853c6ee407d5e136e1b25c27ff34fad Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed > Significant additional code in the engine to perform additional checks and/or name aliasing I know, but we can do very easily one thing - check and throw if overriding method has one or more named parameter on different position. On class creation time, ie. only once, no overhead per call. Then calling with named/unnamed parameters is **consistent** (or resolves to an "Unknown named parameter" error) and... We are safe! With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 28 Oct 2020 17:43, Rowan Tommins wrote: > On 28/10/2020 15:14, Michael Voříšek - ČVUT FEL wrote: > >> I agree - "it's harder to imagine a scenario in real life where". >> [...] >> 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? > > You're thinking about this the wrong way around: the simplest implementation is to detect non-existent named parameters (which happens to include renamed parameters) at run-time; it is additional checks on top of that which need to be justified. > > Other approaches to the problem require at least one of: > > * Significant additional code in the engine to perform additional checks and/or name aliasing > * Users to change existing code which works correctly, but would theoretically break if used with named parameters > > The advantages are almost entirely theoretical, with few realistic examples. > > So the "pragmatic approach" the RFC refers to concludes that the benefit of additional analysis does not outweigh its cost. > > Regards, > > -- > Rowan Tommins (né Collins) > [IMSoP] --=_3853c6ee407d5e136e1b25c27ff34fad--