Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110300
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
In-Reply-To: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
Date: Fri, 29 May 2020 16:32:04 +0200
Message-ID: <CAF+90c9UfZy6Un-XX8yRR8-czTFCc51d3k7TnMnSQtx_Hx12dA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000025534905a6ca5077"
Subject: Re: [RFC] Named arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000025534905a6ca5077
Content-Type: text/plain; charset="UTF-8"

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

--00000000000025534905a6ca5077--