Re: [RFC] Named arguments
| From: | Nikita Popov | Date: | Mon, 08 Jun 2020 12:05:03 +0000 |
| Subject: | Re: [RFC] Named arguments | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-110421@lists.php.net to get a copy of this message | ||
On Fri, Jun 5, 2020 at 3:40 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Fri, Jun 5, 2020 at 12:45 PM Christian Schneider <cschneid@cschneid.com>
> wrote:
>
>> Am 05.05.2020 um 15:51 schrieb Nikita Popov <nikita.ppv@gmail.com>:
>> > \I've now updated the old proposal on this topic, and moved it back
>> under
>> > discussion: https://wiki.php.net/rfc/named_params
>>
>> First of all I really like this approach to Named Parameters: It seems to
>> fit well with the rest of PHP.
>>
>> Note: I'm using the key: 'value' syntax instead of key =>
>> 'value' here
>> but that's just because I prefer that syntax and think it more naturally
>> extends to stuff like the shorthand syntax under "Future Scope" but that's
>> not a prerequisite.
>>
>> I have two questions regarding to the Named Parameters which are not
>> related to the LSP discussion.
>> They might be restrictions of the current implementation mentioned in the
>> RFC as opposed to design restrictions:
>>
>> 1) Could keywords be allowed as parameter names? Currently using class:
>> 'foo' throws a syntax error.
>> 2) Could positional parameters be allowed after named parameters for
>> variadic functions?
>>
>> These two restrictions can be looked at separately and the only reason
>> I'm bringing them up together is because the use case I'm looking at is
>> HTML generation with something like a function div() being used as follows.
>> Please don't discard the two questions just because you don't like this
>> particular use-case, thank you ;-)
>> div(class: 'error',
>> div(class: 'title', "Error Title"),
>> "Detailed error description...",
>> )
>>
>> The first issue is probably mainly a parsing issue and changing T_STRING
>> to identifier seems to fix it though I'm not 100% sure if there are any
>> drawbacks to this.
>>
>
> Right. It should be possible to use keywords. It's a bit harder than just
> replacing T_STRING with identifier, but I don't see any fundamental reason
> why it shouldn't work.
>
I've implemented the necessary groundwork for this in
https://github.com/php/php-src/commit/b03cafd19c01db57b89727ce77cc89a7d816077c,
so now I can say for sure that using keywords as parameter name will work
fine.
Nikita