On Tue, May 5, 2020 at 8:38 PM Lynn <kja...@gmail.com> wrote:
>
>
> 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?
>
Yes, that's what I had in mind. However, after thinking about it a bit, I
don't think adding such functionality is worthwhile in PHP. As Rowan
explained in another mail, the named arguments functionality in Swift is
quite distinct from named arguments in other languages. It is used in a way
that makes it more common for external labels to differ from internal names.
For the rare case where something like this would be useful in PHP, we
already have
function example(string $firstArgument) {
$argument = $firstArgument;
// ...
}
as an existing way to internally rename an argument. If we had reason to
believe that this was commonly needed, then introducing special syntax for
it might make sense. But I don't think think we have such evidence. We do
have some evidence to the contrary in that Swift is the only mainstream
language I'm aware of that has felt it necessary to introduce such a syntax
(and as mentioned, Swift's "named parameters" are really more like "named
functions where part of the name is inside the parameter list").
Regards,
Nikita
