Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110308
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <6f10d1a9-f523-42de-943c-4e9d38f9fffa@www.fastmail.com>
Date: Sat, 30 May 2020 01:02:54 +0200
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID:
 <VI1PR02MB470347D4EA5DBBD461D52784E28F0@VI1PR02MB4703.eurprd02.prod.outlook.com>
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CAF+90c9UfZy6Un-XX8yRR8-czTFCc51d3k7TnMnSQtx_Hx12dA@mail.gmail.com>
 <6f10d1a9-f523-42de-943c-4e9d38f9fffa@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2001:7e8:cb71:d400:d059:57ed:6d5a:2da0] (2001:7e8:cb71:d400:d059:57ed:6d5a:2da0) by LO2P265CA0455.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19 via Frontend Transport; Fri, 29 May 2020 23:02:57 +0000
X-Mailer: Apple Mail (2.3445.104.11)
X-Microsoft-Original-Message-ID:
 <523166F2-D80E-4158-9FCC-4EACEFAAA506@hotmail.com>
X-TMN: [s/subODEMy4xE3PMXOLipGS8zkFivbzAsFZlrMUb/SWl4szJxEq2BESkZx3kvt8D]
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 50
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: e721b7bf-1eb2-49d3-0deb-08d804246d45
X-MS-TrafficTypeDiagnostic: AM7EUR06HT069:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	Pmzrnsl5wpZ21GXPyqVp1+okGjk3BbXGhfFNNF0t9Ub0ExsTmRfu3n9OCEB0BhYIk5XHUXm98DkMZfgSgDitadj9+61tBbGRTCHUeuvVwa2zPe78Medptfg5C+/Vdkf+465BnkV9YEfXnSUq7OPYIofsOs5N8wt5TIxbnNgGsXuMn5QmnYhna9k1aDbpTyCqeKit2SttpEaUHLC3IADoDf0Ny6pOS98t3Efo6Uhkyepj54l5r+TTtyUrHN08lSN9
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR02MB4703.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
X-MS-Exchange-AntiSpam-MessageData:
	ojUJLh/H7fXGa1StaZrqpbNR4/+R86bNnwwFpRSauffbxzMkfHWe7AqFCBQU0NWYhaxx59qgoQ+ORKU/Y6zxkbkHFEn9/I/WfUFdt1/AUu+5p+kBoRKYH8jUpDj6KL7ixIl7nbvahqFIfgf6Xyk+JqfZiKneO6Dx/sQLsFd0QGpdxNPJxrU5BAb7eoi2davzjOvcGSG0DdNSIEcTQQ+Krw==
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e721b7bf-1eb2-49d3-0deb-08d804246d45
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2020 23:02:57.7444
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7EUR06HT069
Subject: Re: [PHP-DEV] Re: [RFC] Named arguments
From: bobwei9@hotmail.com (Bob Weinand)

> Am 29.05.2020 um 21:02 schrieb Larry Garfield <larry@garfieldtech.com>:
>=20
> 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=
:
>>=20
>>> Hi internals,
>>>=20
>>> 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 ob=
ject
>>> ergonomics.
>>>=20
>>> I've now updated the old proposal on this topic, and moved it back unde=
r
>>> discussion: https://wiki.php.net/rfc/named_params
>>>=20
>>> Relative to the last time I've proposed this around PHP 5.6 times, I th=
ink
>>> we're technically in a much better spot now when it comes to the suppor=
t
>>> for internal functions, thanks to the stubs work.
>>>=20
>>> I think the recent acceptance of the attributes proposal also makes thi=
s 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.
>>>=20
>>=20
>> 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:
>>=20
>> 1. When calling a method, also allow using parameter names from the pare=
nt
>> class/interface.
>> 2. During inheritance, enforce that the same parameter name is not used =
at
>> different positions.
>>=20
>> 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 mo=
ved
>> to a different position.
>>=20
>> 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 n=
ot
>> 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 genera=
l
>> impression. And the general impression is that these are indeed legitima=
te
>> LSP violations.
>>=20
>> This approach would be an alternative to either silently ignoring the is=
sue
>> (as the RFC proposed), or to warning for all parameter renames.
>>=20
>> Regards,
>> Nikita
>=20
> Just to make sure I follow what you're proposing, given:
>=20
> class P {
>  public function foo($a, $b, $c) { ... }
> }
>=20
> This is legal:
>=20
> class A extends P {
>  public function foo($a2, $b, $c) {}
> }
>=20
> // Mean the same thing:
> $a =3D (new A)->foo(a =3D 1, b =3D 2, c =3D 3);
> $a =3D (new A)->foo(a2 =3D 1, b =3D 2, c =3D 3);
>=20
> This will parse error:
>=20
> class A extends P {
>  public function foo($b, $a, $c) {}
> }
>=20
> Am I following the intent correctly?
>=20
> If so, that sounds like a very reasonable and safe middle-ground.
>=20
> --Larry Garfield

Yes,

that's pretty much the intent - having a very small BC break surface, while=
 still allowing for safe usage of named parameters according to both the ch=
ild and parent interface.

Bob=