Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111178
MIME-Version: 1.0
References: <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
 <CABHuAWy4C0ng5SnEBM6SybcyvO0+MPiHcVcEvDrFG4fNsf2Opw@mail.gmail.com>
 <CAEPJdu=H1j4C8TvdQF=dbMSKUUM=1-3hVkPf1f3WU-hZgKiy8A@mail.gmail.com>
 <VI1PR02MB4703F7E73D33AF4390337E6DE2770@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <CAF+90c_SY8Hd5ChPM+EtDU6JZgBCjHOYvSq81QHpz9eLnXSDRA@mail.gmail.com> <CAESVnVqy3ovC1a6GaWJOrThYmk=LmbjfEw-+v7muToHEyUsFKw@mail.gmail.com>
In-Reply-To: <CAESVnVqy3ovC1a6GaWJOrThYmk=LmbjfEw-+v7muToHEyUsFKw@mail.gmail.com>
Date: Fri, 24 Jul 2020 18:14:03 +0200
Message-ID: <CAB-BujYqE0gLkzZgnq4aaF=M8ouQrbNnHtE8=8Zy6iSxpeK4Nw@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Bob Weinand <bobwei9@hotmail.com>, 
	Benjamin Eberlei <kontakt@beberlei.de>, Chris Riley <t.carnage@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009a8eba05ab3243cb"
Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters
From: andreas@dqxtech.net (Andreas Hennings)

--0000000000009a8eba05ab3243cb
Content-Type: text/plain; charset="UTF-8"

TLDR
Only consider parameter names from a type-hinted interface, ignore
parameter names from the actual class.

-----

I had a look at
https://wiki.php.net/rfc/named_params#to_parameter_name_changes_during_inheritance
Indeed I have concerns about this, because a call with named arguments
would make your code incompatible with 3rd party implementations of the
interface that do not keep the parameter names.
I would see this as a flaw in a newly added feature, which should be fixed
during the feature freeze.
I might even say the current version as described in the RFC is broken.

I have no objection to the OP's proposal, but would like to add some
alternative ideas to the discussion.

My first idea would be to only consider the parameter names in the original
interface, and ignore all renamed parameters in sub-classes.
This would cause problems if a class implements multiple interfaces that
declare the same method, but with different parameter names.

So, a better idea would be like this:
- The variable must be type-hinted with an interface. E.g. as a parameter
or as object properties.
- named arguments always use the parameter names from the type-hinted
interface.

This would need some static analysis at compile time, and we need to be
able to type-hint regular local variables.

An alternative would be to somehow "import" the parameter names at the top
of the file, somehow like so:

use Acme\Animal::bar;  // Parameter names from this method will be used.

(this syntax probably needs more thought).

Yet another option would be to somehow specify the interface in the method
call..

((\Acme\Animal) $instance)->foo(a: 'A', b: 'B');

Regards
Andreas



On Fri, 24 Jul 2020 at 17:41, Sara Golemon <pollita@php.net> wrote:

> On Fri, Jul 24, 2020 at 10:10 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > > > You added PHP 8.0 as a proposed version, but that will not be
> possible
> > > > anymore 2 weeks of discussion + 2 weeks of voting are not possible to
> fit
> > > > in before the feature freeze, which is in 11 days.
> > >
> > > While you are technically correct, the primary point of a feature
> freeze
> > > is not allowing in completely new features.
> > > It will always happen that there are changes and extensions to RFCs
> > > introduced for the next version which may need to be addressed first,
> > > because there is massive benefit to the new feature in that case. (from
> a
> > > backwards/forwards compatibility standpoint for example)
> > >
> > We should of course be open to making minor adjustments due to
> > unanticipated issues after feature freeze -- after all, that's where we
> > gain experience with new features. The emphasis here is very much on
> > *minor* and *unanticipated* though.
> >
>
> Endorsing this.  Anything post FF needs to be held to a high standard.
> Minor and Unanticipated changes.
> * The option to set alt-names on parameters is substantial.
>  * Making named params explicitly opt-in is less substantial (though
> certainly not trivial), especially if it were hung off an attribute which
> would mean no actual new syntax, but Niki's point that it wasn't an unknown
> or unanticipated issue stands.
>
> I share OP's worry that this pushes workload onto library and framework
> maintainers, and I wouldn't look forward to the review of all APIs to make
> sure their names are correct, but the vote has spoken.  We should
> absolutely continue pursuing this topic with an eye to 8.1 so that library
> updates are less painful moving forward.
>
> -Sara
>

--0000000000009a8eba05ab3243cb--