Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110303
User-Agent: Cyrus-JMAP/3.3.0-dev0-504-g204cd6f-fm-20200527.002-g204cd6f2
Mime-Version: 1.0
Message-ID: <6f10d1a9-f523-42de-943c-4e9d38f9fffa@www.fastmail.com>
In-Reply-To: 
 <CAF+90c9UfZy6Un-XX8yRR8-czTFCc51d3k7TnMnSQtx_Hx12dA@mail.gmail.com>
References: 
 <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CAF+90c9UfZy6Un-XX8yRR8-czTFCc51d3k7TnMnSQtx_Hx12dA@mail.gmail.com>
Date: Fri, 29 May 2020 14:02:11 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Re: [RFC] Named arguments
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 29, 2020, at 9:32 AM, Nikita Popov wrote:
> On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita.ppv@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