# [RFC][VOTE] Allow specifying keys in list() - Thread: https://externals.io/message/91084 - Original archive: https://news-web.php.net/php.internals/91084 - Started by Andrea Faulds on 2016-02-05T12:55:58+00:00 - Messages: 19 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #91084 — Andrea Faulds — 2016-02-05T12:55:58+00:00 URL: https://externals.io/message/91084#91084 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/ --- ## #91095 — Levi Morrison — 2016-02-06T03:58:00+00:00 URL: https://externals.io/message/91084#91095 · In reply to: #91084 > 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/ > > -- > > 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. --- ## #91096 — Marcio Almada — 2016-02-06T05:25:59+00:00 URL: https://externals.io/message/91084#91096 · In reply to: #91095 Hi, 2016-02-05 23:58 GMT-04:00 Levi Morrison : > > > […] > > 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. > > -- > > > "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. --- ## #91098 — Andrea Faulds — 2016-02-06T13:51:08+00:00 URL: https://externals.io/message/91084#91098 · In reply to: #91095 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/ --- ## #91105 — Pierre Joye — 2016-02-08T06:34:58+00:00 URL: https://externals.io/message/91084#91105 · In reply to: #91084 > 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 --- ## #91107 — Yasuo Ohgaki — 2016-02-08T09:08:57+00:00 URL: https://externals.io/message/91084#91107 · In reply to: #91105 Hi, > > > […] > > 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 --- ## #91133 — Andrea Faulds — 2016-02-08T20:18:55+00:00 URL: https://externals.io/message/91084#91133 · In reply to: #91084 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/ --- ## #91138 — Joe Watkins — 2016-02-09T06:50:25+00:00 URL: https://externals.io/message/91084#91138 · In reply to: #91133 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 > 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: > > > […] > > > -- > Andrea Faulds > https://ajf.me/ --- ## #91164 — guilhermeblanco@gmail.com — 2016-02-09T15:36:15+00:00 URL: https://externals.io/message/91084#91164 · In reply to: #91138 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, > 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 > > > > > […] > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #91216 — Joe Watkins — 2016-02-12T11:49:31+00:00 URL: https://externals.io/message/91084#91216 · In reply to: #91164 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: > 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, > > > > > […] > > > > -- > Guilherme Blanco > MSN: guilhermeblanco@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada --- ## #91218 — Bob Weinand — 2016-02-12T12:49:39+00:00 URL: https://externals.io/message/91084#91218 · In reply to: #91164 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, > > > > > […] > > > > -- > Guilherme Blanco > MSN: guilhermeblanco@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada Bob --- ## #91219 — S.A.N — 2016-02-12T13:37:34+00:00 URL: https://externals.io/message/91084#91219 · In reply to: #91218 Often all keys are unknown, or a very lot keys, use list(...) - is unreal. I would like to, instead $value) { $this{$key} = $value } Use the short syntax sugar It's really do? --- ## #91220 — Rowan Collins — 2016-02-12T14:27:20+00:00 URL: https://externals.io/message/91084#91220 · In reply to: #91219 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 > foreach($params as $key => $value) > { > $this{$key} = $value > } > > Use the short syntax sugar > $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. --- ## #91221 — S.A.N — 2016-02-12T14:39:45+00:00 URL: https://externals.io/message/91084#91221 · In reply to: #91220 2016-02-12 16:27 GMT+02:00 Rowan Collins : > S.A.N wrote on 12/02/2016 13:37: > > […] > > 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 --- ## #91222 — Rowan Collins — 2016-02-12T14:55:39+00:00 URL: https://externals.io/message/91084#91222 · In reply to: #91221 S.A.N wrote on 12/02/2016 14:39: > 2016-02-12 16:27 GMT+02:00 Rowan Collins : > > […] > 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] --- ## #91223 — S.A.N — 2016-02-12T15:13:34+00:00 URL: https://externals.io/message/91084#91223 · In reply to: #91222 2016-02-12 16:55 GMT+02:00 Rowan Collins : > S.A.N wrote on 12/02/2016 14:39: > > […] > > > 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) --- ## #91224 — Rowan Collins — 2016-02-12T15:15:08+00:00 URL: https://externals.io/message/91084#91224 · In reply to: #91223 S.A.N wrote on 12/02/2016 15:13: > But is also necessary and the function or operator like > object_assign($target, ...$sources) Like I say, for that kind of purpose, I'd just use an array, which already has the facilities for working with arbitrary keys. But I know some people think $foo->bar "looks prettier" than $foo['bar'], and make big trees of stdClass objects, so maybe it's a matter of taste. --- ## #91225 — S.A.N — 2016-02-12T15:21:20+00:00 URL: https://externals.io/message/91084#91225 · In reply to: #91224 2016-02-12 17:15 GMT+02:00 Rowan Collins : > S.A.N wrote on 12/02/2016 15:13: > > […] > > > Like I say, for that kind of purpose, I'd just use an array, which already > has the facilities for working with arbitrary keys. But I know some people > think $foo->bar "looks prettier" than $foo['bar'], and make big trees of > stdClass objects, so maybe it's a matter of taste. It's not just a matter of taste, the object is always passed by reference, an array is copied when you change, object literal syntax like JSON, sorely lacking in PHP. Probably more correct to focus on the implementation of object literal syntax. Thank. --- ## #91226 — Rowan Collins — 2016-02-12T16:14:42+00:00 URL: https://externals.io/message/91084#91226 · In reply to: #91225 S.A.N wrote on 12/02/2016 15:21: > It's not just a matter of taste, the object is always passed by > reference, an array is copied when you change, object literal syntax > like JSON, sorely lacking in PHP. Objects are passed by *pointer*, because they're expected to have methods that mutate their state in place. An object with arbitrary keys is unlikely to have any such methods, so I still don't really see the point: if you want to manipulate an array in place, put an & in your function signature. If you actually want an object that contains arbitrary data, just have a single property called $data with the array in; that way, you can have "real" (declared) properties alongside, e.g. class CacheItem { private $data = []; private $last_updated; public function __construct($data) { $this->data = $data; $this->last_updated = `time()`; } } You could even implement __get and __set so that the keys of $data were exposed as though they were public properties. stdClass has always seemed completely pointless to me, because it doesn't provide any encapsulation, and making a "real" object (i.e. a declared class, with declared properties) is so easy, and so much more powerful. That's why I call it a matter of taste: if I want a hash, I'll use an array, which is already full-featured; if I want an object, I'll define a class for it and use at least some OO principles. Regards, -- Rowan Collins [IMSoP]