On Tue, May 5, 2020 at 8:22 PM Nikita Popov <nikita....@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
