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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
