# SUMMARY: Array syntax - Thread: https://externals.io/message/34734 - Original archive: https://news-web.php.net/php.internals/34734 - Started by johannes@php.net on 2008-01-11T15:47:05+00:00 - Messages: 24 - 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 --- ## #34734 — johannes@php.net — 2008-01-11T15:47:05+00:00 URL: https://externals.io/message/34734#34734 Hi, I did a short count of the "votes" about the Array Syntax shortcut on the list. I hope I've got everybody right. The results look like that: yes no ---------------------------------- With php-src karma 5 10 Others 16 9 ---------------------------------- Sum 21 19 At large the result is that half the people like it, half the people not. Just counting persons with php-src karma (I hope I didn't miss anybody there or attributed somebody wrong) most people are against it. In my conclusion this means: Rejected. The data with all details as OpenCalc sheet can be found on http://www.schlueters.de/~johannes/php/vote_array_shortcut_20080111.ods If you find errors please answer to this mail in private. johannes --- ## #34739 — Pierre — 2008-01-11T17:37:37+00:00 URL: https://externals.io/message/34734#34739 · In reply to: #34734 > Hi, > > I did a short count of the "votes" about the Array Syntax shortcut on > the list. I hope I've got everybody right. The results look like that: Yes, you forgot me. And restricting the right to vote to php-src only is respectless for all the documentation people. And we can wait at least a week or so before closing the poll. -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #34740 — Pierre — 2008-01-11T17:38:16+00:00 URL: https://externals.io/message/34734#34740 · In reply to: #34739 > > > […] > > Yes, you forgot me. Err, you did not, rest is still valid :) -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #34741 — Stanislav Malyshev — 2008-01-11T17:49:35+00:00 URL: https://externals.io/message/34734#34741 · In reply to: #34734 > I did a short count of the "votes" about the Array Syntax shortcut on > the list. I hope I've got everybody right. The results look like that: There was no "vote", in fact. For example, I am for it and I'm sure my "vote" wasn't counted - simply because I already voiced my support for it last time it was discussed and considered unnecessary to repeat it, since nothing changed. If there's any vote - then it should be announced. I think it's amusing that people start with complaining about too much traffic on the list and everybody having to chime in on every topic, and then end up counting these emails as decisive vote on features. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #34742 — johannes@php.net — 2008-01-11T18:24:02+00:00 URL: https://externals.io/message/34734#34742 · In reply to: #34739 Hi Pierre, > Yes, you forgot me. And restricting the right to vote to php-src only > is respectless for all the documentation people. Well, any restriction there is hard. I know hat the php-src karma is not the best criteria. We have people with karma just for "housekeeping" and others who contributed to discussions in a good way and certainly know what they are taking about without karma. (no, this doesn't mean that these "houskeepers" don't know what they are talking about, just to make clear: php-src-karma is not the best criteria) The general assumption I made is that people with php-src karma who are voting spent more time with the project and might be more experienced with the effect of changes to the language than other people who maybe just yesterday found this list. We don't have any stated criteria for such votes and I doubt there's any good and fair one. An important factor for giving people with karma a bit more weight might be that it are these who are going to maintain the change. Non-developers don't care about the C code and fixing bug reports related to them. But well, that doesn't count for all people with karma of course... Additionally: My conclusion wasn't made only on the php-src-karma people. I also think that a difference from one is not a clear vote and we need, imo, a clear vote/consensus if we want a big change to the syntax. But any vote won't be "fair". So the best thing would be some consensus - but I see no way for reaching a consensus for a question which mainly is a question of taste. Some people like their steaks medium, others well-done and some don't like steaks at all. There's no way to convince them - but endless discussions. But well in my results I have a problem: For Rasmus's vote I've counted a -1 while "as such this syntax is appropriate I think" has to be counted as +1. johannes --- ## #34743 — Pierre — 2008-01-11T18:27:36+00:00 URL: https://externals.io/message/34734#34743 · In reply to: #34742 > But well in my results I have a problem: For Rasmus's vote I've counted > a -1 while "as such this syntax is appropriate I think" has to be > counted as +1. There is more than that. It is too early to close the poll. I is not correct to kick out phpdoc from the poll. And I have some doubts to count as zero the users vote. If we need a poll/interface, why not use the one from PEAR? It should be easy to interface it with the cvs accounts and let vote the right groups of persons. I'm however in favour to give a voice to our users. They are the ones using our softwares... Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #34745 — Sam Barrow — 2008-01-11T18:47:37+00:00 URL: https://externals.io/message/34734#34745 · In reply to: #34743 > > > > […] > > There is more than that. It is too early to close the poll. I is not > correct to kick out phpdoc from the poll. And I have some doubts to > count as zero the users vote. > > If we need a poll/interface, why not use the one from PEAR? It should > be easy to interface it with the cvs accounts and let vote the right > groups of persons. I'm however in favour to give a voice to our users. > They are the ones using our softwares... True. No one's vote is worth more than anyone else's, everybody should have equal say. Some people may know more about the PHP core, but we are all users and developers. It is better to have input from people with a wide range of experience levels, it results in a fairer vote that actually represents the population, rather than putting PHP under the control of a select few. > Cheers, > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org --- ## #34746 — Olivier Hill — 2008-01-11T19:06:54+00:00 URL: https://externals.io/message/34734#34746 · In reply to: #34745 > > True. No one's vote is worth more than anyone else's, everybody should > have equal say. Some people may know more about the PHP core, but we are > all users and developers. Not when some write anything about everything without knowing anything about nothing (makes sense?) > It is better to have input from people with a wide range of experience > levels, it results in a fairer vote that actually represents the > population, rather than putting PHP under the control of a select few. It is not under the control of anyone. The principle is: Contribute and your voice will be louder. It's easy to have a CVS account, and it's easy to fix some bugs and submit patches. That way, you prove that your voice can count and that you at least know what you are talking about (I'm not talking about you in particular, but any user that wants to contribute and have a voting voice that counts) One way could be that votes from internal / phpdoc counts twice as much as people that only leech this list. It's not controlling, but being sure that future decision about the language are made considering the opinions of people really knowing what's at stake. Regards, Olivier --- ## #34747 — Stanislav Malyshev — 2008-01-11T19:07:40+00:00 URL: https://externals.io/message/34734#34747 · In reply to: #34745 > It is better to have input from people with a wide range of experience > levels, it results in a fairer vote that actually represents the > population, rather than putting PHP under the control of a select few. No, it is not. This has nothing to do with "fairness", as we are not enacting laws, levying taxes or distributing subsidies here. To have input from many people is great, moreover - it is necessary. However, it is not the same as deciding by arithmetical majority of votes of whoever cares to vote on technical questions. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #34748 — Sam Barrow — 2008-01-11T19:09:05+00:00 URL: https://externals.io/message/34734#34748 · In reply to: #34746 > > > […] > > Not when some write anything about everything without knowing anything > about nothing (makes sense?) True, however with something like this, it is simply a matter of opinion, not knowledge. [] and array() will have no functional differences. > > […] > > It is not under the control of anyone. The principle is: Contribute > and your voice will be louder. It's easy to have a CVS account, and > it's easy to fix some bugs and submit patches. That way, you prove > that your voice can count and that you at least know what you are > talking about (I'm not talking about you in particular, but any user > that wants to contribute and have a voting voice that counts) True > One way could be that votes from internal / phpdoc counts twice as > much as people that only leech this list. It's not controlling, but > being sure that future decision about the language are made > considering the opinions of people really knowing what's at stake. > Regards, > Olivier --- ## #34749 — Sam Barrow — 2008-01-11T19:13:00+00:00 URL: https://externals.io/message/34734#34749 · In reply to: #34747 > > […] > > No, it is not. This has nothing to do with "fairness", as we are not > enacting laws, levying taxes or distributing subsidies here. To have > input from many people is great, moreover - it is necessary. However, it > is not the same as deciding by arithmetical majority of votes of whoever > cares to vote on technical questions. Which is a valid point in most cases, but this is not technical, it's purely syntactic. If we were voting on implementing a highly advanced technical feature then yes, people who know what they're talking about should be given more weight, but in this case I don't think so. Just voicing my opinion, not that it matters but I just wanted to say something. --- ## #34750 — Steph Fox — 2008-01-11T19:17:58+00:00 URL: https://externals.io/message/34734#34750 · In reply to: #34747 > > […] > > No, it is not. This has nothing to do with "fairness", as we are not > enacting laws, levying taxes or distributing subsidies here. To have input > from many people is great, moreover - it is necessary. However, it is not > the same as deciding by arithmetical majority of votes of whoever cares to > vote on technical questions. Is this one in particular really 'a technical question'? To me it looks more like a simple decision about whether or not to bring new syntax into the core, which would affect every user out there and which is really more to do with peoples' ideas about what constitues simplicity. Most of the time I'd agree that the discussions held on this list are rather more technical by nature and there's a real problem with people who really don't understand the ramifications chiming in, but this is a bit different. - Steph (who has no interest whatever in seeing 500+ emails a week on internals@ or in adding sugar just "because it's there") > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #34752 — Antony Dovgal — 2008-01-11T21:52:10+00:00 URL: https://externals.io/message/34734#34752 · In reply to: #34749 > > […] > > Which is a valid point in most cases, but this is not technical, it's > purely syntactic. Surely it's technical, doesn't matter what exactly it's supposed to affect - its syntax or its functionality. > If we were voting on implementing a highly advanced technical feature > then yes, people who know what they're talking about should be given > more weight, but in this case I don't think so. You're not going to fix bug reports related to the parser, or are you? -- Wbr, Antony Dovgal --- ## #34753 — Pierre — 2008-01-11T22:08:29+00:00 URL: https://externals.io/message/34734#34753 · In reply to: #34752 > > […] > > You're not going to fix bug reports related to the parser, or are you? Neither I will (or if it is an easy one :). Please let move on the right side. It is getting ridiculous to hear this kind of answers. Opinions matter, that's how we evolve. Whether the authors have provided patches or not is irrelevant /for me/. -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #34784 — Sam Barrow — 2008-01-11T22:13:08+00:00 URL: https://externals.io/message/34734#34784 · In reply to: #34752 > > > […] > > Surely it's technical, doesn't matter what exactly it's supposed to > affect - its syntax or its functionality. > > > […] > > You're not going to fix bug reports related to the parser, or are you? I don't know exactly what you mean, and what does that have to do with anything? All I said was a simple fact. This is syntactic, not functional. Some people like looking at square brackets while some don't. Nobody on this thread is more qualified than anybody else on this subject, it's only a matter of opinion. That's it. > -- > Wbr, > Antony Dovgal --- ## #34754 — Antony Dovgal — 2008-01-11T22:35:28+00:00 URL: https://externals.io/message/34734#34754 · In reply to: #34753 > > […] > > Neither I will (or if it is an easy one :). This doesn't mean the issue is purely syntactical and everyone may decide whether it should be implemented or not. People who are going to take care of it and maintain the related code (I do not mean myself) definitely should have more weight in such case. > Please let move on the right side. It is getting ridiculous to hear > this kind of answers. Opinions matter, that's how we evolve. Whether > the authors have provided patches or not is irrelevant /for me/. Well, to me it matters whether the author is going to care of the thing he's proposing or he's going to disappear right after it's implemented. -- Wbr, Antony Dovgal --- ## #34755 — Jeff Griffiths — 2008-01-11T23:20:04+00:00 URL: https://externals.io/message/34734#34755 · In reply to: #34754 Antony Dovgal wrote: ... > Well, to me it matters whether the author is going to care of the thing he's > proposing or he's going to disappear right after it's implemented. I didn't realize there was a section of the code flagged 'syntactic sugar' and only a few people maintained that part. it also seems ridiculous to debate a syntax *addition* such as this in terms of maintainability. Is it really is hard to maintain this patch to the parser? How hard is it to maintain this: $array[] = $foo; ...vs any other part of the codebase? I think a lot of web developers who use PHP would agree with Rasmus' sentiment[1]: "What is clear and understandable to web developers is a moving target. As someone mentioned, nobody who does any sort of web development today can ignore Javascript and they will typically be switching back and forth between Javascript and PHP every couple of minutes. This is our target user these days and as such this syntax is appropriate I think." [1] http://marc.info/?l=php-internals&m=117060700805108&w=2 Jeff --- ## #34756 — Antony Dovgal — 2008-01-11T23:36:48+00:00 URL: https://externals.io/message/34734#34756 · In reply to: #34755 > Antony Dovgal wrote: > ... > > […] > > I didn't realize there was a section of the code flagged 'syntactic > sugar' and only a few people maintained that part. Only a few people maintain the whole project. And that's not a secret. > it also seems ridiculous to debate a syntax *addition* such as this in terms of > maintainability. Is it really is hard to maintain this patch to the parser? Oh, so now we're going to add any new syntax proposed, just because it's so easy to maintain? > How hard is it to maintain this: > > $array[] = $foo; > > ...vs any other part of the codebase? Would you like to try & see? =) -- Wbr, Antony Dovgal --- ## #34757 — Gregory Beaver — 2008-01-12T00:09:15+00:00 URL: https://externals.io/message/34734#34757 · In reply to: #34755 Jeff Griffiths wrote: > Antony Dovgal wrote: > ... > > […] > > I didn't realize there was a section of the code flagged 'syntactic > sugar' and only a few people maintained that part. it also seems > ridiculous to debate a syntax *addition* such as this in terms of > maintainability. Is it really is hard to maintain this patch to the > parser? How hard is it to maintain this: > > $array[] = $foo; > > ...vs any other part of the codebase? Whoa, slow down cowboy! Any change to the parser can have unexpected and even bizarre ramifications in code. For instance, $a = $b([0]); would become perfectly legal syntax, and although it is pretty to those of us who pine after ASCII art, its action is not as obvious as: $a = $b(array(0)); This is just from a user perspective. Now, from an internals perspective, taking a look inside zend_languager_parser.y, currently, it is easy to tell when an array is desired. `T_ARRAY` always portends an array. With the new syntax, this is no longer as deterministic. '[' is used for array initialization as well as array access. Seeing a '[' in isolation, it is not enough information to know whether this is array creation or array access. In fact, as the example above shows, the identical syntax is valid for creation [0] and access [0]. Even with careful attention to precedence and ordering (does '[' bind to the right or the left side of the expression?) it can be very easy to introduce bizarre parse or compile errors. Now, this may sound blunt, but the tone of your message suggests you haven't worked much with parser generators or lexer generators in C. They're one of the more quirky and finicky aspects of PHP internals, and seemingly simple changes can result in ridiculously complex problems. > I think a lot of web developers who use PHP would agree with Rasmus' > sentiment[1]: > > "What is clear and understandable to web developers is a moving target. > As someone mentioned, nobody who does any sort of web development today > can ignore Javascript and they will typically be switching back and > forth between Javascript and PHP every couple of minutes. This is our > target user these days and as such this syntax is appropriate I think." > > [1] http://marc.info/?l=php-internals&m=117060700805108&w=2 Having said all of the above caveats, I personally am on the fence regarding the new syntax. I was also confused when I first started working with PHP about the use of array() for array creation, but this lasted less than an hour, and then I was grateful for the simplicity. Later I grew tired of typing "array", but I type pretty fast, so it's not really an issue. I am used to arrays, and find them intuitive. I am a bit concerned about code like this rearing its head: if (1) { $a = [ [ ['a' => 1, 3], ($b = 3), ] ]; } else { $a = [ [ ['b' => 1, 3] ] ]; } "bracket hell" is not something I've associated with PHP much, and the new syntax would definitely make it possible, but would also simplify the amount of spurious stuff on the screen for me in my work if used well. So, I am +0.5 for [] syntax in principle. I have not examined the patch. Greg --- ## #34758 — Jeff Griffiths — 2008-01-12T00:54:22+00:00 URL: https://externals.io/message/34734#34758 · In reply to: #34757 Gregory Beaver wrote: > Jeff Griffiths wrote: > > […] > > Whoa, slow down cowboy! Ok! > Any change to the parser can have unexpected and even bizarre > ramifications in code. For instance, > > $a = $b([0]); > > would become perfectly legal syntax, and although it is pretty to those > of us who pine after ASCII art, its action is not as obvious as: > > $a = $b(array(0)); That's a matter of perspective, I parse JS code as easily as I do the above, because that's what I'm used to. I do think this type of 'terseness vs readability' debate about this syntax addition is perfectly valid and I think *users* of PHP like myself have a place in that debate. ... > Now, this may sound blunt, but the tone of your message suggests you > haven't worked much with parser generators or lexer generators in C. > They're one of the more quirky and finicky aspects of PHP internals, and > seemingly simple changes can result in ridiculously complex problems. You would be right about that, but I guess I had assumed the patch was solid seeing as no-one has argued against it based on its technical merits. I did qualify the above: "...vs any other part of the codebase?". If there is a technical reason why you shouldn't commit this patch ( it's buggy, etc ) then I am happy to concede the point to people who know much more about this than I do. Most of these threads on this proposal seem to be based on the usability / readability / ephemeral qualities it will bring to PHP, and not on whether it works or not. > I am used to arrays, and find them intuitive. I am a bit concerned > about code like this rearing its head: > > if (1) { > $a = [ > [ > ['a' => 1, 3], > ($b = 3), > ] > ]; > } else { > $a = [ > [ > ['b' => 1, 3] > ] > ]; > } I agree, that's a bit nasty. =) > "bracket hell" is not something I've associated with PHP much, and the > new syntax would definitely make it possible, but would also simplify > the amount of spurious stuff on the screen for me in my work if used well. > > So, I am +0.5 for [] syntax in principle. I have not examined the patch. Assuming the patch is fine ( which I have happily done so far ) it seems this proposal is at best controversial. JeffG --- ## #34759 — Pierre — 2008-01-12T01:02:05+00:00 URL: https://externals.io/message/34734#34759 · In reply to: #34758 > > […] > > I agree, that's a bit nasty. =) Like a string full of variables, arrays and objects can be unreadable :) But I can't stop thinking about code like: [ [-1.0, 0.0, +1.0], [-2.0, 0.0 , +2.0], [-1.0, 0.0, +1.0]] and I will use this new syntax only with such cases like this one :) (variables in string are nice, when used with moderation/caution) -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #34760 — Marcus Boerger — 2008-01-12T11:41:18+00:00 URL: https://externals.io/message/34734#34760 · In reply to: #34748 Hello Sam, and here goes the problem, some people here understand the issue a bit better than others and some people actually do the work because they can and are being respected for - just by their experience... Either way there is a clear functional difference. The old array style syntax looks like a function call, or a contructor. The new one makes one thing clear, you will get an array. marcus Friday, January 11, 2008, 8:09:05 PM, you wrote: > > > […] > True, however with something like this, it is simply a matter of > opinion, not knowledge. [] and array() will have no functional > differences. > > […] > True > > […] Best regards, Marcus --- ## #34783 — Kouber Saparev — 2008-01-14T15:27:11+00:00 URL: https://externals.io/message/34734#34783 · In reply to: #34734 A +1 from me (in case my vote counts). The main reason behind it is readability: $x = array(1 => array(1, 2, 3), array(array(1), 2)); vs. $x = [1 => [1, 2, 3], [[1], 2]]; The latter form looks much better to me - it is faster to read and to understand it (and to type it, of course, although it shouldn't be a factor), especially for such multi-dimensional definitions. The benefit of using the new syntax is even bigger when dealing with function calls + conditionals: if (in_array($z, array(1, 2, 3))) { $s = str_replace(array('a', 'b', 'c'), array('d', 'e', 'f'), 'abc'); } vs. if (in_array($z, [1, 2, 3])) { $s = str_replace(['a', 'b', 'c'], ['d', 'e', 'f'], 'abc'); } With the "square brackets" syntax a pair of redundant parantheses is removed, thus making it easier to distinguish between data definition and function call (conditional, expression...) closures and helping identify arrays among such compound structures. ;-) Regards, -- Kouber Saparev http://kouber.saparev.com --- ## #34794 — Richard Lynch — 2008-01-15T22:12:22+00:00 URL: https://externals.io/message/34734#34794 · In reply to: #34784 > > > […] > > I don't know exactly what you mean, and what does that have to do with > anything? > > All I said was a simple fact. This is syntactic, not functional. > Some people like looking at square brackets while some don't. Nobody > on > this thread is more qualified than anybody else on this subject, it's > only a matter of opinion. That's it. His point is that it IS functional. Somewhere in the guts of PHP there is a lexical parser that has to deal with the nifty new syntax, and do the right thing with it, and if it doesn't work right, somebody somewhere has to deal with the bug reports about it being broken. Somebody has to write the patch, somebody has to maintain the resulting code. Somebody has to take on the task of documenting the new syntax. Somebody has to answer all the questions on PHP-General about how the new syntax works. And so on. There is no such thing as a non-functional change, if you are touching the C code. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So?