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
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
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.
Err, you did not, rest is still valid :)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
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
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,
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...
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,
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
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?)
True, however with something like this, it is simply a matter of
opinion, not knowledge. [] and array() will have no functional
differences.
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)
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
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. 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?)
True, however with something like this, it is simply a matter of
opinion, not knowledge. [] and array() will have no functional
differences.
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)
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
Best regards,
Marcus
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
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.
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.
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.
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
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?
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
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?
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
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
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.
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
Jeff Griffiths wrote:
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?
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."
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
Gregory Beaver wrote:
Jeff Griffiths wrote:
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?
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
if (1) {
$a = [
[
['a' => 1, 3],
($b = 3),
]
];
} else {
$a = [
[
['b' => 1, 3]
]
];
}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
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.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?
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
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.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?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?
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.
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
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
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