Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110011
To: Marco Pivetta <ocramius@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
CC: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Named arguments
Thread-Index: AQHWIuRQgEnh5uGy6EupES3pBJ/NLqiZiEkAgAAun/Q=
Date: Tue, 5 May 2020 16:59:25 +0000
Message-ID:
 <BYAPR05MB65351D7E676F6ABD5EBF3D99DEA70@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>,<CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
In-Reply-To:
 <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [aWCoqmTmRftKKpqOse2X5oT2FPhguzgJ]
x-ms-publictraffictype: Email
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: d8a81dff-84c1-40e2-c602-08d7f115aa5d
x-ms-traffictypediagnostic: BN8NAM12HT155:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 lsNs8QDXCDJ7g9b7GUusdWjPEq/GB1r7KaYdewoYor/cIcjpbFKYsys10CBGG+c5Xoryeyk4L/cFbyv0X4TQ7hPgyDLfMWGtC7cV7aYgGXBk2zIKT+nNZa9LDaO8FR+vjEa18dAeh+h02SjQCiDjqsVFL3hcnk2PUzyD8Ar3Abezo9ZHaduAQEwFQkRBqgoyVKn0mwRCgjrlHM2HzsEa3Q==
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:
 rYPw/r3GtxTu/tzMw4Lumds9QSuaptMSu9XnPCMwtag2JkGP9Gmxllq50OWLEW7pDhqbFlsv9xB7jjQ8X+3X0C5SApiMDzMXt3pJeBKxwppPIwxqEPJvCsashNzLm9+elrtermu/X9Rqa17PSVS34Q==
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-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d8a81dff-84c1-40e2-c602-08d7f115aa5d
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 16:59:25.0494
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM12HT155
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: theodorejb@outlook.com (Theodore Brown)

On Tue, May 5, 2020 at 9:11 AM Marco Pivetta <ocramius@gmail.com> wrote:=0A=
=0A=
> As mentioned some days ago, I see named parameters as an added liability,=
=0A=
> rather than values.=0A=
> The rationale of my negativity around the topic being that a diff like=0A=
> following is now to be considered a BC break:=0A=
> =0A=
> ```diff=0A=
> -function foo($parameterName) { /* ... */ }=0A=
> +function foo($newParameterName) { /* ... */ }=0A=
> ```=0A=
=0A=
If the function is part of your own codebase, an IDE can automatically=0A=
update function calls when renaming a parameter. For functions that are=0A=
part of a public API, yes, parameters shouldn't be renamed outside of=0A=
major versions. But in my experience, it's rare for function parameters=0A=
that are part of public APIs to be renamed. Do you have many real-world=0A=
examples of where this had to happen?=0A=
=0A=
Also, I haven't heard of this being a big problem in other languages=0A=
with named arguments like Python.=0A=
=0A=
> the feature seems to be especially designed to work with particularly=0A=
> bad API (anything with a gazillion optional parameters, such as all=0A=
> the OpenSSL nightmares in php-src).=0A=
=0A=
Why do you say that? For me this feature would be extremely helpful=0A=
when calling constructors that have several optional arguments (e.g.=0A=
similar to the `ParamNode` example in the RFC). Maybe you consider=0A=
this a bad API, but it's a very common pattern, and named arguments=0A=
will make it far easier to work with than the typical alternative of=0A=
converting arguments to an options array (which is itself a BC break=0A=
and has many other downsides as the RFC points out).=0A=
=0A=
> In practice, the issues around bad API (in this case, bad =3D lots of=0A=
> optional parameters, maybe even ordered arbitrarily) are fixed by=0A=
> using proper value types and structs or value objects=0A=
=0A=
How can lots of optional parameters be "fixed" in practice with structs?=0A=
E.g. how would they improve the `ParamNode` example in the RFC? Would=0A=
it even be possible to migrate existing classes like this to structs=0A=
without a BC break?=0A=
=0A=
Personally I think it's a lot simpler and more consistent to have named=0A=
arguments which can be used anywhere, including in attributes, vs.=0A=
having to implement and learn a new syntax for structs which only works=0A=
for that one use case (and may not be easy to migrate to).=0A=
=0A=
Best regards,=0A=
=0A=
Theodore Brown=0A=