Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110785
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: [RFC] Named arguments
Thread-Index: AQHWSUaG8sG+Bi+LHk+5vTsbTFlm/ajvvTOAgAAatZk=
Date: Mon, 29 Jun 2020 16:49:57 +0000
Message-ID:
 <BYAPR05MB65359F68BA290A625E52CC6FDE6E0@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CAF+90c_hndba0oLbL-BX9i3N-1Dhy=R2xW-hq6C0Rv2j3mKcTQ@mail.gmail.com>,<CAF+90c8jwAk4RnGCVMC=e-L_OnvYYjnK69gUiKgGEMe26WDZdA@mail.gmail.com>
In-Reply-To:
 <CAF+90c8jwAk4RnGCVMC=e-L_OnvYYjnK69gUiKgGEMe26WDZdA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [tUngdZH0Fo5jidlRZTCphGCKmZfC8in2]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 9be8b5a5-b285-4ab1-ee21-08d81c4c751e
x-ms-traffictypediagnostic: MW2NAM10HT148:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 v8zT2B16CZwCuKyKENjU+xyUMbCigbKX3FCT5euQrhs1EGT+7G1dyYrJZ87g3v46YBKMNgheUsEGaqu4bH4Gwyvr5tup9Dk93nmBzJ0jUCrBD6zfI3QLEiTqRyxk72r+40a/G7NbeA5gx20Q3+WmE7PssLUXyd1glXoKxKZfrMhY5kQrkJ6wSTbv0NIAD8I49p68EjnIDixJOMfzs23AiJLohtW4KkViA1aIDHQkRxSqurdMYF+KJtJn8QSxSlGe
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR05MB6535.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 b9CVNpzoUfYE4z5tj3s1oGqUTMNYK4C/YvuUA1QXaXbpz+0JqADiTx32lmg1ZwUttzDZAugigEd/YlczI3yjlXxG3BHcU+ICCSmKHIlq05Bp/ej/12xQ5vNASK32Gf9BIaWAdrYbE2a2zZhlHtlHew==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM10FT025.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 9be8b5a5-b285-4ab1-ee21-08d81c4c751e
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 16:49:57.9599
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM10HT148
Subject: Re: [PHP-DEV] Re: [RFC] Named arguments
From: theodorejb@outlook.com (Theodore Brown)

On Mon, June 29, 2020 at 10:13 AM Nikita Popov <nikita.ppv@gmail.com> wrote=
:=0A=
=0A=
> On Tue, Jun 23, 2020 at 12:10 PM Nikita Popov <nikita.ppv@gmail.com> wrot=
e:=0A=
> =0A=
> > As we're moving in on feature freeze, I plan to move this proposal forw=
ard=0A=
> > soonishly.=0A=
> >=0A=
> > I have update the RFC to drop the syntax as an open question (I haven't=
=0A=
> > seen much opposition to the use of ":"), and to describe the possible=
=0A=
> > alternative LSP behavior at=0A=
> > https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inh=
eritance.=0A=
> >=0A=
> > While writing this down and implementing it, I found that this has more=
=0A=
> > odd edge-cases than anticipated. Overall, I'm not sold that this approa=
ch=0A=
> > is worth it. It sounds nice on paper, but I strongly suspect that it so=
lves=0A=
> > a problem that does not existing in practice, and will force us to keep=
=0A=
> > this patch-over mechanism indefinitely, while the real solution would h=
ave=0A=
> > been to fix the limited amount of code that is in the intersection of=
=0A=
> > "renames parameters" and "is actually invoked with named arguments".=0A=
> =0A=
> Just as another reminder: I plan to put this to voting by the end of the=
=0A=
> week.=0A=
> =0A=
> I've also updated the RFC to make the LSP behavior a secondary vote. I'm=
=0A=
> not convinced this is a good idea myself, but some others seemed to prefe=
r=0A=
> this approach.=0A=
=0A=
Hi Nikita,=0A=
=0A=
Thanks for moving this forward. Currently I work with a lot of value=0A=
objects which are constructed from an associative array (requiring=0A=
lots of manual validation), and named arguments will make it feasible=0A=
to migrate most of these to simple typed parameters that can be=0A=
statically analyzed instead. For me at least this will be one of the=0A=
nicest features in PHP 8.=0A=
=0A=
I'm also looking forward to the potential future shorthand syntax=0A=
for matching parameter and variable names, which could also reduce=0A=
boilerplate in array construction and destructuring.=0A=
=0A=
I'll probably vote No on the secondary "Automagically allow using=0A=
parent parameter names?" vote. This is a feature that could always be=0A=
added later without a BC break, but if it's added now it would be=0A=
hard to remove if the extra complexity causes problems. For these=0A=
rare cases it's probably better to update the parameter names to=0A=
match or stick with normal sequential arguments.=0A=
=0A=
Best regards,=0A=
Theodore=0A=