Re: [RFC] Allow specifying keys in list()
| From: | Pierre Joye | Date: | Mon, 18 Jan 2016 04:54:24 +0000 |
| Subject: | Re: [RFC] Allow specifying keys in list() | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-90689@lists.php.net to get a copy of this message | ||
hi Andrea,
I very much like this proposal. Good work as usual!
The only part where I think we should not rely on list is the future
scope. I can see the logic that leads to use list for named arguments.
However I really think it is a very different topic and having to use
list to define arguments, it sounds like a hack to solve another long
due feature. Anyway, as it is not part of this RFC, I will ignore it
for now :)
Keep the good work,
Cheers,
Pierre
On Mon, Jan 18, 2016 at 9:07 AM, Andrea Faulds <ajf@ajf.me> wrote:
> Hi Bishop,
>
>
> Bishop Bettini wrote:
>>
>> On Sat, Jan 16, 2016 at 9:32 PM, Andrea Faulds <ajf@ajf.me> wrote:
>>
>>> Hi everyone,
>>>
>>> Here's an RFC that would extend the syntax of list() to be more useful
>>> with associative arrays:
>>>
>>> https://wiki.php.net/rfc/list_keys
>>>
>>> Please read it and tell me your thoughts.
>>>
>>
>> Nice, Andrea, thanks! Destructuring is quite handy.
>>
>> I wonder if there is opportunity to include array gathering. Something
>> along the lines of:
>>
>> list ('foo' => $foo, ...$rest) = [ 'foo' => 1, 'bar'
>> => 2, 'baz' => 3];
>> assert $foo === 1;
>> assert $rest === [ 'bar' => 2, 'baz' => 3];
>>
>> What do you think?
>
>
> That might be useful, and it's certainly intuitive. In languages with linked
> lists like Haskell, you can pattern-match the rest of a list, so there's a
> precedent. Though with linked lists it's an O(1) operation, while this is
> O(n).
>
> I don't think that should go into this RFC specifically, though, but it
> could be a future enhancement.
>
>
> Thanks!
> --
> Andrea Faulds
> https://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Pierre
@pierrejoye | http://www.libgd.org