Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][VOTE] Allow specifying keys in list() »

[RFC][VOTE] Allow specifying keys in list()

php.internals

Andrew Faulds

10 years ago
Hi everyone, It's been more than two weeks since I first proposed this RFC, and there's no outstanding issues preventing moving towards a vote. There's not yet a language specification patch, but that can be done later. So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close the Sunday after next, 2016-02-14. The vote requires a 2/3 majority as it's a language change. The RFC page is here: https://wiki.php.net/rfc/list_keys Happy voting!
-- Andrea Faulds https://ajf.me/

Levi Morrison

10 years ago
On Fri, Feb 5, 2016 at 5:55 AM, Andrea Faulds <ajf@ajf.me> wrote:
> Hi everyone, > > It's been more than two weeks since I first proposed this RFC, and there's > no outstanding issues preventing moving towards a vote. There's not yet a > language specification patch, but that can be done later. > > So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close the > Sunday after next, 2016-02-14. The vote requires a 2/3 majority as it's a > language change. > > The RFC page is here: https://wiki.php.net/rfc/list_keys > > Happy voting! > -- > Andrea Faulds > https://ajf.me/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
I wanted to chime in since I voted no. I'm not strongly opposed to this behavior but I do have concerns about the key behavior that was changed. In an example in the RFC: list($foo => $bar) = $array; I don't think this really makes sense. `$foo` is being evaluated and its value is used to look up the key in `$array`, but `$bar` is being assigned to even though it's a similar place as `$foo`. I don't think I've really expressed well what I am trying to convey but I think this RFC would be much better *without* this change, so I've voted no.

Marcio Almada

10 years ago
Hi, 2016-02-05 23:58 GMT-04:00 Levi Morrison <levim@php.net>:
> On Fri, Feb 5, 2016 at 5:55 AM, Andrea Faulds <ajf@ajf.me> wrote: >> Hi everyone, >> >> It's been more than two weeks since I first proposed this RFC, and there's >> no outstanding issues preventing moving towards a vote. There's not yet a >> language specification patch, but that can be done later. >> >> So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close the >> Sunday after next, 2016-02-14. The vote requires a 2/3 majority as it's a >> language change. >> >> The RFC page is here: https://wiki.php.net/rfc/list_keys >> >> Happy voting! >> -- >> Andrea Faulds >> https://ajf.me/ >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php > > I wanted to chime in since I voted no. I'm not strongly opposed to > this behavior but I do have concerns about the key behavior that was > changed. In an example in the RFC: > > list($foo => $bar) = $array; > > I don't think this really makes sense. `$foo` is being evaluated and > its value is used to look up the key in `$array`, but `$bar` is being > assigned to even though it's a similar place as `$foo`. > > I don't think I've really expressed well what I am trying to convey > but I think this RFC would be much better *without* this change, so > I've voted no. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
"yes" voter here... I'm not 100% sure if I understand your concern perfectly. Evaluating the key as an expression seems to make sense, specially on examples like: ``` list( CURLOPT_GET => $isGet, CURLOPT_POST => $isPost, CURLOPT_URL => $url ) = $curlOptions; ``` Would you mind to elaborate more why do you think this is a problem? :) Thank you, Márcio.

Andrew Faulds

10 years ago
Hi Levi, Levi Morrison wrote:
> I wanted to chime in since I voted no. I'm not strongly opposed to > this behavior but I do have concerns about the key behavior that was > changed. In an example in the RFC: > > list($foo => $bar) = $array; > > I don't think this really makes sense. `$foo` is being evaluated and > its value is used to look up the key in `$array`, but `$bar` is being > assigned to even though it's a similar place as `$foo`. > > I don't think I've really expressed well what I am trying to convey > but I think this RFC would be much better *without* this change, so > I've voted no.
Well, this is why we have discussion periods. I brought this up before as an open issue. Nobody told me they objected to it, and everyone who did respond told me they favoured the current behaviour. I decided, therefore, that the risk of confusion was low.
-- Andrea Faulds https://ajf.me/

Pierre Joye

10 years ago
On Fri, Feb 5, 2016 at 7:55 PM, Andrea Faulds <ajf@ajf.me> wrote:
> Hi everyone, > > It's been more than two weeks since I first proposed this RFC, and there's > no outstanding issues preventing moving towards a vote. There's not yet a > language specification patch, but that can be done later. > > So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close the > Sunday after next, 2016-02-14. The vote requires a 2/3 majority as it's a > language change. > > The RFC page is here: https://wiki.php.net/rfc/list_keys > > Happy voting!
I voted yes as I like some use cases and the obvious syntax. However I almost voted no because of the examples about usage as a half backed named argument, covered in future scope. I mentioned it during the discussion phase but I will vote against this kind of things as real named arguments support would be by far superior than that, for the record here :) Cheers,
-- Pierre @pierrejoye | http://www.libgd.org

Yasuo Ohgaki

10 years ago
Hi, On Mon, Feb 8, 2016 at 3:34 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Fri, Feb 5, 2016 at 7:55 PM, Andrea Faulds <ajf@ajf.me> wrote: >> Hi everyone, >> >> It's been more than two weeks since I first proposed this RFC, and there's >> no outstanding issues preventing moving towards a vote. There's not yet a >> language specification patch, but that can be done later. >> >> So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close the >> Sunday after next, 2016-02-14. The vote requires a 2/3 majority as it's a >> language change. >> >> The RFC page is here: https://wiki.php.net/rfc/list_keys >> >> Happy voting! > > I voted yes as I like some use cases and the obvious syntax.
Same here. It's simply pain to use numeric indexes. There are good use cases other than named parameter like usage. This syntax decreases likelihood that wrong values are assigned to variables by list(), which is good for code reliability/security. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Andrew Faulds

10 years ago
Hi again, There's been a lot of No votes on this RFC, but I haven't received much feedback as to why. Would any of you mind sharing your reasons, if possible? It would be helpful if I knew why people have voted against it, as then I might be able to modify the RFC to be more palatable, or understand where I went wrong. Thanks! Andrea Faulds wrote:
> Hi everyone, > > It's been more than two weeks since I first proposed this RFC, and > there's no outstanding issues preventing moving towards a vote. There's > not yet a language specification patch, but that can be done later. > > So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close > the Sunday after next, 2016-02-14. The vote requires a 2/3 majority as > it's a language change. > > The RFC page is here: https://wiki.php.net/rfc/list_keys > > Happy voting!
-- Andrea Faulds https://ajf.me/

Joe Watkins

10 years ago
Morning internalz, As mentioned the future scope stuff is scary, but not enough on it's own to vote no. So I want to vote yes, but I'm just waiting to hear objections from no voters, in case they thought of something I didn't ... Cheers Joe On Mon, Feb 8, 2016 at 8:18 PM, Andrea Faulds <ajf@ajf.me> wrote:

Guilherme Blanco

10 years ago
Here is my reasons for no: 1- Non-intuitive behavior 2- Hard to read code, takes more time to understand underlying logic/flow 3- YAANPI => Yet Another Alternate Named Parameters Implementation (when I look at future scope) 4- Most common usage form (first example) still forces you to type almost same amount of logic with less readability and little value Regards, On Tue, Feb 9, 2016 at 1:50 AM, Joe Watkins <pthreads@pthreads.org> wrote:
> Morning internalz, > > As mentioned the future scope stuff is scary, but not enough on it's > own to vote no. > > So I want to vote yes, but I'm just waiting to hear objections from no > voters, in case they thought of something I didn't ... > > Cheers > Joe > > On Mon, Feb 8, 2016 at 8:18 PM, Andrea Faulds <ajf@ajf.me> wrote: > > > Hi again, > > > > There's been a lot of No votes on this RFC, but I haven't received much > > feedback as to why. Would any of you mind sharing your reasons, if > > possible? It would be helpful if I knew why people have voted against it, > > as then I might be able to modify the RFC to be more palatable, or > > understand where I went wrong. > > > > Thanks! > > > > > > Andrea Faulds wrote: > > > >> Hi everyone, > >> > >> It's been more than two weeks since I first proposed this RFC, and > >> there's no outstanding issues preventing moving towards a vote. There's > >> not yet a language specification patch, but that can be done later. > >> > >> So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close > >> the Sunday after next, 2016-02-14. The vote requires a 2/3 majority as > >> it's a language change. > >> > >> The RFC page is here: https://wiki.php.net/rfc/list_keys > >> > >> Happy voting! > >> > > > > > > -- > > Andrea Faulds > > https://ajf.me/ > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
-- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada

Joe Watkins

10 years ago
Morning, 1 - I'm not completely certain what you are referring too ... list() has always felt a bit strange to me and this doesn't feel any stranger imo. 2 - Perhaps I agree, but perhaps I tend to think that it's because I'm not used to looking at it yet. 3 - This isn't relevant at the moment. 4 - This is only example illustrative code. It isn't always about how many characters you have to type ... public function __construct(array $things) { $options = $things + $this->defaults; $this->apples = $options["apples"]; $this->oranges = $options["oranges"]; } This is a pretty common pattern ... I much prefer this: public function __construct(array $things) { list ( "apples" => $this->apples, "oranges" => $this->oranges ) = ($things + $this->defaults); } Not because it's less characters (although it is, by one), but because it's more expressive. Anyway +1 from me ... even if it's a bit late ... Cheers Joe On Tue, Feb 9, 2016 at 3:36 PM, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote:

Bob Weinand

10 years ago
Hmm, I have to disagree… 1. Just as intuitive as the whole list() construct. I don’t see where this particular addition adds any strangeness. For your readability/hard to read code problem I think the RFC is just doing a bad formatting job: list("name" => $this->name, "colour" => $this->colour, "age" => $this->age, "cuteness" => $this->cuteness) = $attributes; Would be how I’d format that. Makes it pretty obvious which keys are used (nice list from top to bottom) and makes it nicely visible what the origin array is, it being very prominently on the right. And at that point (also that I only have to parse the origin array only once) it presents a nice readability improvement. And the 3. point regarding future scope is irrelevant. It’s something this RFC would make possible, but it by far doesn’t mean that it will ever come - it’s just future scope. Ignore it. Hence I ultimately think this RFC is a good idea. Thanks, Bob
> Am 9.2.2016 um 16:36 schrieb guilhermeblanco@gmail.com: > > Here is my reasons for no: > > 1- Non-intuitive behavior > 2- Hard to read code, takes more time to understand underlying logic/flow > 3- YAANPI => Yet Another Alternate Named Parameters Implementation (when I > look at future scope) > 4- Most common usage form (first example) still forces you to type almost > same amount of logic with less readability and little value > > Regards, > > On Tue, Feb 9, 2016 at 1:50 AM, Joe Watkins <pthreads@pthreads.org> wrote: > >> Morning internalz, >> >> As mentioned the future scope stuff is scary, but not enough on it's >> own to vote no. >> >> So I want to vote yes, but I'm just waiting to hear objections from no >> voters, in case they thought of something I didn't ... >> >> Cheers >> Joe >> >> On Mon, Feb 8, 2016 at 8:18 PM, Andrea Faulds <ajf@ajf.me> wrote: >> >>> Hi again, >>> >>> There's been a lot of No votes on this RFC, but I haven't received much >>> feedback as to why. Would any of you mind sharing your reasons, if >>> possible? It would be helpful if I knew why people have voted against it, >>> as then I might be able to modify the RFC to be more palatable, or >>> understand where I went wrong. >>> >>> Thanks! >>> >>> >>> Andrea Faulds wrote: >>> >>>> Hi everyone, >>>> >>>> It's been more than two weeks since I first proposed this RFC, and >>>> there's no outstanding issues preventing moving towards a vote. There's >>>> not yet a language specification patch, but that can be done later. >>>> >>>> So, I'm opening the vote on this RFC today, 2016-02-05, and it'll close >>>> the Sunday after next, 2016-02-14. The vote requires a 2/3 majority as >>>> it's a language change. >>>> >>>> The RFC page is here: https://wiki.php.net/rfc/list_keys >>>> >>>> Happy voting! >>>> >>> >>> >>> -- >>> Andrea Faulds >>> https://ajf.me/ >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> > > > > -- > Guilherme Blanco > MSN: guilhermeblanco@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada
Bob

Alex Sky

10 years ago
Often all keys are unknown, or a very lot keys, use list(...) - is unreal. I would like to, instead <?php foreach($params as $key => $value) { $this{$key} = $value } Use the short syntax sugar <?php $this += $params ?> It's really do?

Rowan Collins

10 years ago
S.A.N wrote on 12/02/2016 13:37:
> Often all keys are unknown, or a very lot keys, use list(...) - is unreal. > > I would like to, instead <?php > > foreach($params as $key => $value) > { > $this{$key} = $value > } > > Use the short syntax sugar <?php > > $this += $params > > ?> > > It's really do? >
If the keys are unknown, then you probably don't want to blindly copy them onto object properties; at that point, you might as well just have $this->data and leave them as an array. It sounds like what you actually want is an object literal syntax - i.e. $params should never have been an array in the first place.

Alex Sky

10 years ago
2016-02-12 16:27 GMT+02:00 Rowan Collins <rowan.collins@gmail.com>:
> S.A.N wrote on 12/02/2016 13:37: >> >> Often all keys are unknown, or a very lot keys, use list(...) - is unreal. >> >> I would like to, instead <?php >> >> foreach($params as $key => $value) >> { >> $this{$key} = $value >> } >> >> Use the short syntax sugar <?php >> >> $this += $params >> >> ?> >> >> It's really do? >> > > If the keys are unknown, then you probably don't want to blindly copy them > onto object properties; at that point, you might as well just have > $this->data and leave them as an array. It sounds like what you actually > want is an object literal syntax - i.e. $params should never have been an > array in the first place. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I would operator (+=) as like to function Object.assign() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign

Rowan Collins

10 years ago
S.A.N wrote on 12/02/2016 14:39:
> 2016-02-12 16:27 GMT+02:00 Rowan Collins <rowan.collins@gmail.com>: >> S.A.N wrote on 12/02/2016 13:37: >>> Often all keys are unknown, or a very lot keys, use list(...) - is unreal. >>> >>> I would like to, instead <?php >>> >>> foreach($params as $key => $value) >>> { >>> $this{$key} = $value >>> } >>> >>> Use the short syntax sugar <?php >>> >>> $this += $params >>> >>> ?> >>> >>> It's really do? >>> >> If the keys are unknown, then you probably don't want to blindly copy them >> onto object properties; at that point, you might as well just have >> $this->data and leave them as an array. It sounds like what you actually >> want is an object literal syntax - i.e. $params should never have been an >> array in the first place. >> > I would operator (+=) as like to function Object.assign() > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign
Sure, but I was thinking more in terms of whether this is a strong use case for having it. In JS, "Object" is the appropriate type for an arbitrary hash of key-value pairs. In PHP, the appropriate type for such a structure is "array", which already supports the + operator and array_merge function. Note that the method you linked doesn't copy from an array onto an object, it copies from one object to another. Doing the same in PHP leaves the question of how you create the right-hand object, which is why I mentioned "object literal syntax", i.e. the ability to write something like "{ a => 42, b => 'Hello' }" or "new Foo { a => 42, b => 'Hello' }" to define an object with directly-specified property values, rather than running the constructor. The constructor example using list() syntax is deliberately naming the fields we're interested in, because it's populating an object of a particular class, with known property names, not dynamically creating arbitrary property keys. Regards,
-- Rowan Collins [IMSoP]

Alex Sky

10 years ago
2016-02-12 16:55 GMT+02:00 Rowan Collins <rowan.collins@gmail.com>:
> S.A.N wrote on 12/02/2016 14:39: >> >> 2016-02-12 16:27 GMT+02:00 Rowan Collins <rowan.collins@gmail.com>: >>> >>> S.A.N wrote on 12/02/2016 13:37: >>>> >>>> Often all keys are unknown, or a very lot keys, use list(...) - is >>>> unreal. >>>> >>>> I would like to, instead <?php >>>> >>>> foreach($params as $key => $value) >>>> { >>>> $this{$key} = $value >>>> } >>>> >>>> Use the short syntax sugar <?php >>>> >>>> $this += $params >>>> >>>> ?> >>>> >>>> It's really do? >>>> >>> If the keys are unknown, then you probably don't want to blindly copy >>> them >>> onto object properties; at that point, you might as well just have >>> $this->data and leave them as an array. It sounds like what you actually >>> want is an object literal syntax - i.e. $params should never have been an >>> array in the first place. >>> >> I would operator (+=) as like to function Object.assign() >> >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign > > > Sure, but I was thinking more in terms of whether this is a strong use case > for having it. In JS, "Object" is the appropriate type for an arbitrary hash > of key-value pairs. In PHP, the appropriate type for such a structure is > "array", which already supports the + operator and array_merge function. > > Note that the method you linked doesn't copy from an array onto an object, > it copies from one object to another. Doing the same in PHP leaves the > question of how you create the right-hand object, which is why I mentioned > "object literal syntax", i.e. the ability to write something like "{ a => > 42, b => 'Hello' }" or "new Foo { a => 42, b => 'Hello' }" to define an > object with directly-specified property values, rather than running the > constructor. > > The constructor example using list() syntax is deliberately naming the > fields we're interested in, because it's populating an object of a > particular class, with known property names, not dynamically creating > arbitrary property keys. > > Regards, > -- > Rowan Collins > [IMSoP] >
I agree, list() syntax and object literal syntax - is need, +1 But is also necessary and the function or operator like object_assign($target, ...$sources)