> Am 29.05.2020 um 21:02 schrieb Larry Garfield <la...@garfieldtech.com>: > > On Fri, May 29, 2020, at 9:32 AM, Nikita Popov wrote: >> On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita....@gmail.com> wrote: >> >>> Hi internals, >>> >>> I've recently started a thread on resurrecting the named arguments >>> proposal (https://externals.io/message/109549), as this has come up >>> tangentially in some recent discussions around attributes and around object >>> ergonomics. >>> >>> I've now updated the old proposal on this topic, and moved it back under >>> discussion: https://wiki.php.net/rfc/named_params >>> >>> Relative to the last time I've proposed this around PHP 5.6 times, I think >>> we're technically in a much better spot now when it comes to the support >>> for internal functions, thanks to the stubs work. >>> >>> I think the recent acceptance of the attributes proposal also makes this a >>> good time to bring it up again, as phpdoc annotations have historically had >>> support for named arguments, and this will make migration to the >>> language-provided attributes smoother. >>> >> >> 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. >> >> Regards, >> Nikita > > Just to make sure I follow what you're proposing, given: > > class P { > public function foo($a, $b, $c) { ... } > } > > This is legal: > > class A extends P { > public function foo($a2, $b, $c) {} > } > > // Mean the same thing: > $a = (new A)->foo(a = 1, b = 2, c = 3); > $a = (new A)->foo(a2 = 1, b = 2, c = 3); > > This will parse error: > > class A extends P { > public function foo($b, $a, $c) {} > } > > Am I following the intent correctly? > > If so, that sounds like a very reasonable and safe middle-ground. > > --Larry Garfield
Yes, that's pretty much the intent - having a very small BC break surface, while still allowing for safe usage of named parameters according to both the child and parent interface. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
