Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110816 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 6199 invoked from network); 2 Jul 2020 12:30:45 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 2 Jul 2020 12:30:45 -0000 To: internals@lists.php.net References: Date: Thu, 2 Jul 2020 13:20:10 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 46.59.72.204 Subject: Re: [RFC] Named arguments From: ajf@ajf.me (Andrea Faulds) Message-ID: Hi, Nikita Popov wrote: > > Regarding the question of what to do with regard to LSP validation and > parameter names changing during inheritance: During internal discussion, > the following option has come up as a possible compromise: > > 1. When calling a method, also allow using parameter names from the parent > class/interface. > 2. During inheritance, enforce that the same parameter name is not used at > different positions. > > This ensures that renaming parameter names during inheritance does not > break code relying on parameter names of the parent method. At the same > time, it prohibits genuine LSP violations, where a parameter has been moved > to a different position. > > I've run some static analysis to detect cases that would be affected by the > latter check, with these results: > https://gist.github.com/nikic/6cc9891381a83b8dca5ebdaef1068f4d The first > signature is the child method, and the second the parent method. I did not > put in the effort to make this completely precise, so there's both false > positives and false negatives here. But it should be enough for a general > impression. And the general impression is that these are indeed legitimate > LSP violations. > > This approach would be an alternative to either silently ignoring the issue > (as the RFC proposed), or to warning for all parameter renames. Would this do anything surprising when variadics are involved? Regards, Andrea