Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110020
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
 <BYAPR05MB65351D7E676F6ABD5EBF3D99DEA70@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CADyq6sLgKy5xhh5f9ptV5wNEWQ7e5LwqjZc2_-8FoRtq=Yv6rA@mail.gmail.com> <CAF+90c8MQgXwNGsx8zcgkYWBkmJEO7wCum-6+yyAYt=yC_+_-A@mail.gmail.com>
In-Reply-To: <CAF+90c8MQgXwNGsx8zcgkYWBkmJEO7wCum-6+yyAYt=yC_+_-A@mail.gmail.com>
Date: Tue, 5 May 2020 20:37:44 +0200
Message-ID: <CANS-=pe4bscX2D2pig3Ef2gbwutR0hX-yUknEm=YFoAXQkk4dA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, Theodore Brown <theodorejb@outlook.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000018d28005a4eaf3c8"
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: kjarli@gmail.com (Lynn)

--00000000000018d28005a4eaf3c8
Content-Type: text/plain; charset="UTF-8"

On Tue, May 5, 2020 at 8:22 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> Anyway. Your point that named arguments expand the API surface has been
> acknowledged. I don't think this issue is really avoidable, it's a rather
> fundamental trade-off of named parameters. I do think you're a bit quick in
> jumping to conclusions. It's not like this problem doesn't exist in
> (nearly) every language supporting named arguments.
>
> There are some things we can do to mitigate this though. One that we
> recently discussed in chat is to allow methods to change parameters during
> inheritance, and allow named arguments to refer to the parameter names of
> the parent method as well. Renaming parameters in a way that causes
> conflicts (same parameter name at different position) would cause an LSP
> error. I'm not entirely convinced this is the best approach yet, but this
> does address some concerns (including the "interface extraction" concern
> you mention on reddit).
>
> Another is to allow specifying the public parameter name and the private
> parameter variable name separately, as is possible in Swift. This would
> allow changing "parameter" names arbitrarily, without breaking the public
> API. This would be a pretty direct counter to your concern, but I'm not
> really sure that your concern is important enough to warrant the additional
> weight in language complexity. I've never used Swift myself, so maybe this
> is actually awesome and I just don't know it.
>
> Regards,
> Nikita
>

Hi,

If I understand this correctly, something like this could be done?

```
// current version, argument name = "firstArgument"
function example(string $firstArgument) {}
// name changes, bc can be kept, argument name = "firstArgument" and
"argument"
function example(string firstArgument: $argument) {}
```
This would make it possible to keep backwards compatibility, and perhaps
even trigger a notice when called with the old name?

Regards,
Lynn

--00000000000018d28005a4eaf3c8--