# Shorthand proposal for associative arrays - Thread: https://externals.io/message/101698 - Original archive: https://news-web.php.net/php.internals/101698 - Started by Christian Schneider on 2018-01-26T18:16:26+00:00 - Messages: 13 - 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 --- ## #101698 — Christian Schneider — 2018-01-26T18:16:26+00:00 URL: https://externals.io/message/101698#101698 Hi there, I have a proposal for a shorthand notation of associative arrays borrowed from another language: :$foo would be equivalent to 'foo' => $foo and would work with array, list or [] Motivation behind it, maybe someone else finds more good uses: 1) Emulating named parameters with associative arrays like html::img([ 'src' => $src, 'alt' => $alt ]); could be written as html::img([ :$src, :$alt ]); which encourages consistent naming of variables and parameters 2) Simplifying list destructuring with non-integer keys, example taking from http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list foreach ($data as ["id" => $id, "name" => $name]) { becomes foreach ($data as [ :$id, :$name ]) { which reduces redundancy. I implemented a minimal patch (2 lines are added to the parser) to implement this which you can find at https://cschneid.com/php/php7_2/assoc_array_shorthand.patch What do you think, is this worth an RFC? I hope I didn't miss an existing one :-) Regards, - Chris --- ## #101701 — David Rodrigues — 2018-01-26T20:00:29+00:00 URL: https://externals.io/message/101698#101701 · In reply to: #101698 Maybe you should see the `extract()` method. It will receive strings as varargs and will create an associative array with the string name and the value, similar to your first example. html::img(extract('src', 'alt')); 2018-01-26 16:16 GMT-02:00 Christian Schneider : > Hi there, > I have a proposal for a shorthand notation of associative arrays borrowed > from another language: > :$foo > would be equivalent to > 'foo' => $foo > and would work with array, list or [] > > Motivation behind it, maybe someone else finds more good uses: > > 1) Emulating named parameters with associative arrays like > html::img([ 'src' => $src, 'alt' => $alt ]); > could be written as > html::img([ :$src, :$alt ]); > which encourages consistent naming of variables and parameters > > 2) Simplifying list destructuring with non-integer keys, example taking > from http://php.net/manual/en/migration71.new-features.php# > migration71.new-features.support-for-keys-in-list > foreach ($data as ["id" => $id, "name" => $name]) { > becomes > foreach ($data as [ :$id, :$name ]) { > which reduces redundancy. > > I implemented a minimal patch (2 lines are added to the parser) to > implement this which you can find at > https://cschneid.com/php/php7_2/assoc_array_shorthand.patch > > What do you think, is this worth an RFC? I hope I didn't miss an existing > one :-) > > Regards, > - Chris > > > -- > > > > -- David Rodrigues --- ## #101702 — David Rodrigues — 2018-01-26T20:01:32+00:00 URL: https://externals.io/message/101698#101702 · In reply to: #101701 Sorry, the `extract()` function will receives an array as first argument. html::img(extract(['src', 'alt']); 2018-01-26 18:00 GMT-02:00 David Rodrigues : > Maybe you should see the `extract()` method. It will receive strings as > varargs and will create an associative array with the string name and the > value, similar to your first example. > > html::img(extract('src', 'alt')); > > > 2018-01-26 16:16 GMT-02:00 Christian Schneider : > > > […] > > > -- > David Rodrigues > -- David Rodrigues --- ## #101707 — Michael Morris — 2018-01-26T21:31:50+00:00 URL: https://externals.io/message/101698#101707 · In reply to: #101701 On Fri, Jan 26, 2018 at 2:00 PM, David Rodrigues wrote: > Maybe you should see the `extract()` method. Uhm, what? You need to learn what extract does before you recommend it as an alternative to someone's proposal. Extract takes an array and moves their keys onto the local symbol table. So extract( ['src' => 'myimg.jpg', 'alt' => 'My alt']); echo $src; // myimg.jpg echo $alt; // My alt Using extract on an array with numeric keys gives you fun stuff like $0, $1 and so on. Extract sees most of its use in PHP based template management classes where an associative array is extracted than a template file is included, to allow the template file to use the key names as variables rather than the array syntax. As to the proposal itself. > Motivation behind it, maybe someone else finds more good uses: > > 1) Emulating named parameters with associative arrays like > html::img([ 'src' => $src, 'alt' => $alt ]); > could be written as > html::img([ :$src, :$alt ]); > which encourages consistent naming of variables and parameters I've been mulling this over since I saw it earlier today. It's kinda neat to be honest. --- ## #101708 — Michael Morris — 2018-01-26T21:39:28+00:00 URL: https://externals.io/message/101698#101708 · In reply to: #101698 Forgot something in the previous post... On Fri, Jan 26, 2018 at 12:16 PM, Christian Schneider wrote: > Hi there, > I have a proposal for a shorthand notation of associative arrays borrowed > from another language: > :$foo > would be equivalent to > 'foo' => $foo > and would work with array, list or [] > > Motivation behind it, maybe someone else finds more good uses: > > 1) Emulating named parameters with associative arrays like > html::img([ 'src' => $src, 'alt' => $alt ]); > could be written as > html::img([ :$src, :$alt ]); > which encourages consistent naming of variables and parameters > The most similar extant feature to this is compact, but it's not as compact as this syntax. $src = 'my.jpg'; $alt = 'My alt'; html::img(compact($src, $alt)); will accomplish the same thing since compact does the reverse of extract - it pulls the specified variables from the local scope and puts them into an associative array. --- ## #101709 — David Rodrigues — 2018-01-26T21:49:10+00:00 URL: https://externals.io/message/101698#101709 · In reply to: #101708 Sorry. I mean "compact()" instead of `extract()` (it basically does the oposite hehe), I confused everything in a hurry. Sorry. So the real example is: html::img(compact('src', 'alt')); 2018-01-26 19:39 GMT-02:00 Michael Morris : > Forgot something in the previous post... > > On Fri, Jan 26, 2018 at 12:16 PM, Christian Schneider < > cschneid@cschneid.com > > […] > > > […] > > The most similar extant feature to this is compact, but it's not as compact > as this syntax. > > $src = 'my.jpg'; > $alt = 'My alt'; > html::img(compact($src, $alt)); > > will accomplish the same thing since compact does the reverse of extract - > it pulls the specified variables from the local scope and puts them into an > associative array. > -- David Rodrigues --- ## #101710 — Fleshgrinder — 2018-01-26T21:51:33+00:00 URL: https://externals.io/message/101698#101710 · In reply to: #101698 > Hi there, > I have a proposal for a shorthand notation of associative arrays borrowed from another language: > :$foo > would be equivalent to > 'foo' => $foo > and would work with array, list or [] > > Motivation behind it, maybe someone else finds more good uses: > > 1) Emulating named parameters with associative arrays like > html::img([ 'src' => $src, 'alt' => $alt ]); > could be written as > html::img([ :$src, :$alt ]); > which encourages consistent naming of variables and parameters > > 2) Simplifying list destructuring with non-integer keys, example taking from http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list > foreach ($data as ["id" => $id, "name" => $name]) { > becomes > foreach ($data as [ :$id, :$name ]) { > which reduces redundancy. > > I implemented a minimal patch (2 lines are added to the parser) to implement this which you can find at > https://cschneid.com/php/php7_2/assoc_array_shorthand.patch > > What do you think, is this worth an RFC? I hope I didn't miss an existing one :-) > > Regards, > - Chris > > Hi Chris! I really like this proposal. `compact` is cumbersome to use, or lets say, almost impossible without an intelligent IDE. However, what is more important is the fact that is would allow for a very readable and usable approach for destructuring of associative arrays (as illustrated by your example) which is very, very neat. The change is also extremely minimal which speaks for it. I would support you in writing up an RFC for this (if desired). -- Richard "Fleshgrinder" Fussenegger --- ## #101711 — Richard Jennings — 2018-01-26T22:44:10+00:00 URL: https://externals.io/message/101698#101711 · In reply to: #101710 In my opinion this suggestion reduces readability and increases cognative burden and as such I hope it is not included. Regards > > > […] > borrowed from another language: > > […] > from > http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list > > […] > implement this which you can find at > > […] > existing one :-) > > […] > > Hi Chris! > > I really like this proposal. `compact` is cumbersome to use, or lets > say, almost impossible without an intelligent IDE. However, what is more > important is the fact that is would allow for a very readable and usable > approach for destructuring of associative arrays (as illustrated by your > example) which is very, very neat. The change is also extremely minimal > which speaks for it. > > I would support you in writing up an RFC for this (if desired). > > -- > Richard "Fleshgrinder" Fussenegger > > -- > > > > -- Richard Jennings Jennings Technology Limited Company Number: 09827512 VAT Number: 224 8864 84 --- ## #101713 — Rowan Collins — 2018-01-27T14:14:04+00:00 URL: https://externals.io/message/101698#101713 · In reply to: #101698 Hi! > Hi there, > I have a proposal for a shorthand notation of associative arrays borrowed from another language: > :$foo > would be equivalent to > 'foo' => $foo > and would work with array, list or [] I'm always a little suspicious of features that give meaning to the name of a variable, because I consider variable names to be an important part of the readability of code, and the encapsulation of an implementation. As such, I want to be able to rename local variables as part of tweaking how a particular function is written. For instance, I'm not in favour of introducing named parameters based on existing function signatures, because it makes names which were previously local into part of the function's public signature. While this particular proposal doesn't prevent refactoring in the way named parameters would, it adds one more thing to trip up on: when renaming $foo to $bar, [:$foo] needs to be changed to ['foo' => $bar]. > 1) Emulating named parameters with associative arrays like > html::img([ 'src' => $src, 'alt' => $alt ]); > could be written as > html::img([ :$src, :$alt ]); > which encourages consistent naming of variables and parameters This smells of bad code to me: it either means your functions are very closely coupled, and the variables have exactly the same meaning in both scopes; or that one or other name is poorly chosen, and doesn't reflect its meaning in the scope where it's used. In this example, $alt would probably have come from some other string, which could more appropriately be labelled $productName, or $bookTitle, or whatever the image is showing. If the values are constructed just for this function call, I would prefer to read:     html::img([          'src' => $imageDomain . $coverImagePath,          'alt' => "$bookTitle by $authorName"     ]); as opposed to:    $src = $coverImagePath . $coverImagePath;    $alt = "$bookTitle by $authorName";    html::img([ :$src, :$alt ]); > 2) Simplifying list destructuring with non-integer keys, example taking from http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list > foreach ($data as ["id" => $id, "name" => $name]) { > becomes > foreach ($data as [ :$id, :$name ]) { > which reduces redundancy. This example feels a bit more compelling, but again it assumes that you want the local name to match the array key, rather than having a name appropriate to the current task. For instance, you might well be dealing with other things which have IDs and names, and want to differentiate:    foreach( $bookList as ["id" => $bookId, "name" => $bookName ] ) { I'm not dead against this proposal, but it's not one I'd be using often myself, and personally I think it would lead to more bad code than good. Regards, -- Rowan Collins [IMSoP] --- ## #101714 — Sara Golemon — 2018-01-27T23:29:38+00:00 URL: https://externals.io/message/101698#101714 · In reply to: #101709 > Sorry. I mean "compact()" instead of `extract()` (it basically does the > oposite hehe), I confused everything in a hurry. Sorry. > > So the real example is: html::img(compact('src', 'alt')); > > 2018-01-26 19:39 GMT-02:00 Michael Morris : > > > […] > I see nothing in this proposal that compact doesn't already do quite well. -1 --- ## #101715 — Christian Schneider — 2018-01-28T02:51:08+00:00 URL: https://externals.io/message/101698#101715 · In reply to: #101714 Am 28.01.2018 um 00:29 schrieb Sara Golemon : > > > […] > I see nothing in this proposal that compact doesn't already do quite well. Yes, it is syntactic sugar to remove verbosity. Using `compact()` has two problems for me: 1) It is verbose especially if the assoc-as-poor-man's-named-parameter approach is used frequently. A bit like array() vs. []. 2) More importantly: It hides the variable being used: 'src' instead of $src which makes it harder to search for the variable or statically analyse the code. - Chris --- ## #101716 — Markus Fischer — 2018-01-28T06:54:53+00:00 URL: https://externals.io/message/101698#101716 · In reply to: #101715 Hi, > 2) More importantly: It hides the variable being used: 'src' instead of $src which makes it harder to search for the variable or statically analyse the code. I'm not sure about that argument. `compact()` been around basically since forecer. Modern PHP IDEs do support this already and I'm pretty sure static analyzers do too (I now for a fact that both PhpStorm and phpstan support it). In contrast, I've this argument: With `compact()` you have a clear call acting as a boundary when such a behaviour is used. Use the direct-variable syntax doesn't give you that because you would at least know the name of a variable or apply regular expression for such but I bet you can't easily use any tool at hand like you could with compact. Is this _more_ relevant than your arguments? I'm not to judge :) But I too believe `compact()` serves well and covers everything and the proposal is one more thing to put alternative syntax for something already possible. I also weight that it's practical impact is much more less then compared to e.g. the coalesce operator. That ons is also just syntax sugar but it really made an impact to the language because that pattern is very very common. I don't think this applies to `compact()`; it only has very special use-cases (and it's not only templating…), I see it in almost every project I work and (and use it myself) and I never felt something "fix-worthy" with it. - Markus --- ## #101717 — Andrey Andreev — 2018-01-28T07:47:23+00:00 URL: https://externals.io/message/101698#101717 · In reply to: #101715 Hi, I've got mixed feelings about this ... On one hand, I've always avoided `compact()` because it is magic; a hack that was very obviously made because there was no language construct for it. This would've spared me lots of annoyance with code that was already otherwise boring. But on the other hand ... > Yes, it is syntactic sugar to remove verbosity. Using `compact()` has two problems for me: > 1) It is verbose especially if the assoc-as-poor-man's-named-parameter approach is used frequently. A bit like array() vs. []. array() vs [] is an entirely different level of frequency. If you're using `compact()` even remotely as much as arrays in general, it sounds more like you're abusing those poor-mans-named-params. The use cases for that should be limited to stuff like PDO's named parameter markers, not literally every function. And to speculate a bit, if your variable names always match the desired array key names, then you're probably (and paradoxically) already being verbose with stuff like $src = $url. For the few valid use cases where the names do 100% match, `compact()` (while I do hate it) already does the job and it isn't *that* verbose. Cheers, Andrey.