[PHP-DEV] Proposal: Array syntax
Christian Schneider
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
I propose to add an alternative (backward compatible) short array
creation syntax:
$a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
It can also be used in function calls:
img(['src' => "logo.gif", 'alt' => "Logo"]);
Reason behind this change: Arrays are used a lot and should therefore
have as little syntactic overhead as possible. And I think the short
syntax is also easier to read and write.
A patch for the parser is trivial and is attached for Zend2.
Note: I checked the newsgroup archive but couldn't find a discussion
about this. After not hearing back about my proposed enhancement to
debug_backtrace() and the dangling comma for function call parameters
being rejected I wonder if I'm using the right mailing list for this :-)
- Chris
--------------000102040006030200070405
Content-Type: text/plain;
name="short_array_syntax.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="short_array_syntax.patch"
Index: Zend/zend_language_parser.y
===================================================================
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.127
diff -u -r1.127 zend_language_parser.y
--- Zend/zend_language_parser.y 19 Oct 2003 08:38:48 -0000 1.127
+++ Zend/zend_language_parser.y 4 Nov 2003 23:32:12 -0000
@@ -581,6 +581,7 @@
| '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } expr { zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }
| scalar { $$ = $1; }
| T_ARRAY '(' array_pair_list ')' { $$ = $3; }
+ | '[' array_pair_list ']' { $$ = $2; }
| '`' encaps_list '`' { zend_do_shell_exec(&$$, &$2 TSRMLS_CC); }
| T_PRINT expr { zend_do_print(&$$, &$2 TSRMLS_CC); }
;
--------------000102040006030200070405
Content-Type: text/plain; charset=us-ascii
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--------------000102040006030200070405--
Andi Gutmans
Personally I don't like having two ways of doing things. It makes it harder
for people to read scripts.
However, I think the proposed syntax is significantly more elegant than
today's array() which makes me think twice about the idea and possibly
making an exception to the rule. I think it'll improve the look of PHP
scripts. Also I think people calling methods using call_user_method([$obj,
"method"]); will find it sexier than the array() syntax.
I guess I think it'd be interesting to see what other's think. Also,
another point to check is if list() can also be converted into [] because
having a hybrid wouldn't be too nice.
Andi
At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote:
>I propose to add an alternative (backward compatible) short array creation
>syntax:
>$a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
>
>It can also be used in function calls:
>img(['src' => "logo.gif", 'alt' => "Logo"]);
>
>Reason behind this change: Arrays are used a lot and should therefore have
>as little syntactic overhead as possible. And I think the short syntax is
>also easier to read and write.
>
>A patch for the parser is trivial and is attached for Zend2.
>
>Note: I checked the newsgroup archive but couldn't find a discussion about
>this. After not hearing back about my proposed enhancement to
>debug_backtrace() and the dangling comma for function call parameters
>being rejected I wonder if I'm using the right mailing list for this :-)
>
>- Chris
>
>
>Index: Zend/zend_language_parser.y
>===================================================================
>RCS file: /repository/ZendEngine2/zend_language_parser.y,v
>retrieving revision 1.127
>diff -u -r1.127 zend_language_parser.y
>--- Zend/zend_language_parser.y 19 Oct 2003 08:38:48 -0000 1.127
>+++ Zend/zend_language_parser.y 4 Nov 2003 23:32:12 -0000
>@@ -581,6 +581,7 @@
> | '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } expr {
> zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }
> | scalar { $$ = $1; }
> | T_ARRAY '(' array_pair_list ')' { $$ = $3; }
>+ | '[' array_pair_list ']' { $$ = $2; }
> | '`' encaps_list '`' { zend_do_shell_exec(&$$,
> &$2 TSRMLS_CC); }
> | T_PRINT expr { zend_do_print(&$$, &$2 TSRMLS_CC); }
> ;
>
Michael Walter
How about supporting .. syntax, btw. as in [1..3] or ["a".."z"]? Might
no be the worth, just thinking out loud ;)
Christian Schneider wrote:
> I propose to add an alternative (backward compatible) short array
> creation syntax:
> $a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
>
> It can also be used in function calls:
> img(['src' => "logo.gif", 'alt' => "Logo"]);
>
> Reason behind this change: Arrays are used a lot and should therefore
> have as little syntactic overhead as possible. And I think the short
> syntax is also easier to read and write.
>
> A patch for the parser is trivial and is attached for Zend2.
>
> Note: I checked the newsgroup archive but couldn't find a discussion
> about this. After not hearing back about my proposed enhancement to
> debug_backtrace() and the dangling comma for function call parameters
> being rejected I wonder if I'm using the right mailing list for this :-)
>
> - Chris
>
>
> ------------------------------------------------------------------------
Michael Walter
>
> How about supporting .. syntax, btw. as in [1..3] or ["a".."z"]? Might
> no be the worth, just thinking out loud ;)
Kouber Saparev
I would like to have these in PHP.
Kouber
"Michael Walter" <c...@leetspeak.org> wrote in message
news:3FA8BC03...@leetspeak.org...
> Very cool.
>
> How about supporting .. syntax, btw. as in [1..3] or ["a".."z"]? Might
> no be the worth, just thinking out loud ;)
>
Christian Schneider
> I guess I think it'd be interesting to see what other's think. Also,
> another point to check is if list() can also be converted into []
> because having a hybrid wouldn't be too nice.
Having list() work the same way would be very sexy indeed:
[$a, $b] = [$b, $a];
To be honest I never really liked the distinction between list() and
array().
Using [] for arrays is also consistent with dereferenceing arrays and
therefore shouldn't confuse people really.
My first shot at extending the parser to allow [] for list() failed
though as both T_LIST and T_ARRAY are used in expr_without_variable. But
I'm sure you could find a clever way around this, my knowledge of yacc
is still limited :-)
But even without [] for list() I think [] for array() would be nice ;-)
- Chris
Ford, Mike [LSS]
> At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote:
>> I propose to add an alternative (backward compatible) short
>> array creation syntax: $a = [ 1, 2, 3 ]; and $a = [ 'a' =>
>> 42, 'b' => "foo" ];
>
> Personally I don't like having two ways of doing things. It
> makes it harder
> for people to read scripts.
> However, I think the proposed syntax is significantly more
> elegant than
> today's array() which makes me think twice about the idea and
> possibly making an exception to the rule. I think it'll
> improve the
> look of PHP
> scripts. Also I think people calling methods using
> call_user_method([$obj,
> "method"]); will find it sexier than the array() syntax.
> I guess I think it'd be interesting to see what other's think.
I would be greatly in favour of the [] construct. I've used a number of
languages over the years which feature this kind of syntax (a current
example being JavaScript), and always found the array() syntax clumsy by
comparison.
(And, to answer another thread, personally I don't think it's any more
"magic" than the use of [] to access individual array elements -- and the
two are so clearly related that once you know what one does it would be easy
to guess the meaning of the other.)
Cheers!
Mike
---------------------------------------------------------------------
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
Cesare D'Amico
> However, I think the proposed syntax is significantly more elegant than
> today's array() which makes me think twice about the idea and possibly
> making an exception to the rule. I think it'll improve the look of PHP
bj,
> "method"]); will find it sexier than the array() syntax.
This syntax is really pythonian... I can see python programmers prouding=20
themselves as "trend makers" in programming languages ;)
Ciao
ce
--=20
"L'Informatica riguarda i computer tanto quanto l'astronomia riguarda i=20
telescopi"
-- E. W. Dijkstra
Alexey Trunyov
> Personally I don't like having two ways of doing things. It makes it
> harder for people to read scripts.
It looks like the one way of doing two separate things.
I mean that semanics of two usages of square brackets as operator is
inverse depending on whether it is used in unary or binary form.
Being unary, square brackets operator is array constructor.
And being applied to left-side variable it becomes a reference to an
array element.
These two usages do some sort of inverse stuff.
BTW is [1][0]==1 true with the proposed syntax?
> However, I think the proposed syntax is significantly more elegant than
> today's array() which makes me think twice about the idea and possibly
> making an exception to the rule. I think it'll improve the look of PHP
> scripts. Also I think people calling methods using
> call_user_method([$obj, "method"]); will find it sexier than the array()
> syntax.
> I guess I think it'd be interesting to see what other's think. Also,
> another point to check is if list() can also be converted into []
> because having a hybrid wouldn't be too nice.
That was what I think although I am not the one to listened to.
> Andi
>
> At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote:
>
>> I propose to add an alternative (backward compatible) short array
>> creation syntax:
>> $a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
>>
>> It can also be used in function calls:
>> img(['src' => "logo.gif", 'alt' => "Logo"]);
>>
>> Reason behind this change: Arrays are used a lot and should therefore
>> have as little syntactic overhead as possible. And I think the short
>> syntax is also easier to read and write.
>>
>> A patch for the parser is trivial and is attached for Zend2.
>>
>> Note: I checked the newsgroup archive but couldn't find a discussion
>> about this. After not hearing back about my proposed enhancement to
>> debug_backtrace() and the dangling comma for function call parameters
>> being rejected I wonder if I'm using the right mailing list for this :-)
>>
>> - Chris
--
Antony Dovgal
Alexey Trunyov <a...@forest.akadem.ru> wrote:
> Andi Gutmans wrote:
>
> > Personally I don't like having two ways of doing things. It makes it
> > harder for people to read scripts.
>
> It looks like the one way of doing two separate things.
No, it looks like someone trying to turn PHP into Perl (or Python).
Personally I would prefer not to import Perl-style & Python-style syntax to PHP.
These things already work well(yes, you can think, that array() & range() are ugly, but they are already used in tonns of projects) and I can't see any reasons to change such fundamental things just because version number changes from 4 to 5.
If you really like this syntax - use Perl or Python, or whatever you want, but I really can't understand why PHP should allow you to use this syntax too.
---
WBR,
Antony Dovgal aka tony2001
tony...@phpclub.net
Marco Tabini
From a logical standpoint, I think this could be very confusing. To me,
for one, square brackets imply reference, not assignment. Taking
something that means "take something out of the array" and now using it
to mean "put something in the array" makes the language a bit less
self-consistent... and, as Rasmus mentioned, less readable. Conciveness
is not everything--one also has to be able to understand his own code
after he's written it :-)
Cheers,
Marco
Andi Gutmans wrote:
> Hi Christian,
>
> Personally I don't like having two ways of doing things. It makes it
> harder for people to read scripts.
> However, I think the proposed syntax is significantly more elegant than
> today's array() which makes me think twice about the idea and possibly
> making an exception to the rule. I think it'll improve the look of PHP
> scripts. Also I think people calling methods using
> call_user_method([$obj, "method"]); will find it sexier than the array()
> syntax.
> I guess I think it'd be interesting to see what other's think. Also,
> another point to check is if list() can also be converted into []
> because having a hybrid wouldn't be too nice.
>
> Andi
>
> At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote:
>
>> I propose to add an alternative (backward compatible) short array
>> creation syntax:
>> $a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
>>
>> It can also be used in function calls:
>> img(['src' => "logo.gif", 'alt' => "Logo"]);
>>
>> Reason behind this change: Arrays are used a lot and should therefore
>> have as little syntactic overhead as possible. And I think the short
>> syntax is also easier to read and write.
>>
>> A patch for the parser is trivial and is attached for Zend2.
>>
>> Note: I checked the newsgroup archive but couldn't find a discussion
>> about this. After not hearing back about my proposed enhancement to
>> debug_backtrace() and the dangling comma for function call parameters
>> being rejected I wonder if I'm using the right mailing list for this :-)
>>
>> - Chris
>>
>>
>> Index: Zend/zend_language_parser.y
>> ===================================================================
>> RCS file: /repository/ZendEngine2/zend_language_parser.y,v
>> retrieving revision 1.127
>> diff -u -r1.127 zend_language_parser.y
>> --- Zend/zend_language_parser.y 19 Oct 2003 08:38:48 -0000 1.127
>> +++ Zend/zend_language_parser.y 4 Nov 2003 23:32:12 -0000
>> @@ -581,6 +581,7 @@
>> | '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } expr {
>> zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }
>> | scalar { $$ = $1; }
>> | T_ARRAY '(' array_pair_list ')' { $$ = $3; }
>> + | '[' array_pair_list ']' { $$ = $2; }
>> | '`' encaps_list '`' {
>> zend_do_shell_exec(&$$, &$2 TSRMLS_CC); }
>> | T_PRINT expr { zend_do_print(&$$, &$2 TSRMLS_CC); }
>> ;
>>
Magnus Määttä
Ilia Alshanetsky <il...@prohost.org> wrote:
> I do not like the new syntax at all. If anything it seems rather unnatural and > what do you save, typing of 5 characters that makes it clear that this is an
> array to even the most novice of users? It certainly not going to make the
> code any faster and if anything will only add confusion.
>
> Firm -1.
I totally agree with Ilia.
And it doesn't take more than 0.4 seconds to type "array" anyway.
array("My 0.2c, " => "Magnus");
--
What does it mean if there is no fortune for you?
Derick Rethans
> I do not like the new syntax at all. If anything it seems rather unnatural and
> what do you save, typing of 5 characters that makes it clear that this is an
> array to even the most novice of users? It certainly not going to make the
> code any faster and if anything will only add confusion.
>
> Firm -1.
Right, one point of confusion is using [] both for initialising array
and indexing them. I'm -1 on this too, array() and range() wosk fine.
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-------------------------------------------------------------------------
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/
-------------------------------------------------------------------------
Christian Schneider
went too far ;-)
Antony Dovgal wrote:
> No, it looks like someone trying to turn PHP into Perl (or Python).
I'm just trying to improve PHP. And I write _a lot_ of PHP code, so I
have some idea about where the syntax could be improved IMHO.
> Personally I would prefer not to import Perl-style & Python-style syntax to PHP.
PHP is a mix of C, Perl and other styles anyway, why deny it? It's
strength is that it's a pragmatic and simple language but that doesn't
mean that nothing should be changed ever.
> These things already work well(yes, you can think, that array() & range()
> are ugly, but they are already used in tonns of projects) and I can't see
I don't want to break existing programs. And I don't care about range()
(or even list() too much for that matter), I just recognize the fact the
I'm using a lot of array() and it is both unnecessarily hard to write
_and_ read.
Saying that array() works well and [] is incomprehensible just does not
match my experience. Both for myself (some years of programming
experience) and for newbies. I saw no difference teaching people to
initialize an array with array() or []. Someone new to programming has
to memorize that he has to write $a = array() (and not $a = new array()
for example) anyway, $a = [] would be just as easy IMHO.
> any reasons to change such fundamental things just because version number
> changes from 4 to 5.
So why was the whole private/public/static/throw/catch thing introduced?
Following your logic people who want this should use Java. I'm much
more worried about code getting unreadable because of these extensions
actually. It turned PHP into a much more complex language but since it
is all optional I don't mind. But to deny some simple (and backward
compatible) syntactic sugar to people who just want an easy to use
language seems missing the point to me.
> If you really like this syntax - use Perl or Python, or whatever you want,
> but I really can't understand why PHP should allow you to use this
syntax too.
I like some of the Python syntax. But some of it is cumbersome. Same
with PHP. But I think PHP is closer to what I want so what's wrong with
trying to improve it where it's possible (and easily done)? I used Perl
4 back in the early days but I was horrified by some stuff they added
with Perl 5. Perl 6 is actually making some things better again (but no,
I'm not going to use it when it comes out in 2010).
[ 'my_cents' => .02 ],
- Chris
Nicolas Toper
I'm new to the list. I've come trough your post and as a PHP "end user" I
can say that array are easy to use but they could be a lot easier...
You don't want Perl features? Please don't delete the for each operator :=)
-----Message d'origine-----
De : Christian Schneider [mailto:csch...@cschneid.com]
Envoye : mercredi 5 novembre 2003 16:35
A : Antony Dovgal
Cc : inte...@lists.php.net
Objet : Re: [PHP-DEV] Proposal: Array syntax
Ilia Alshanetsky
> PHP is a mix of C, Perl and other styles anyway, why deny it? It's
> strength is that it's a pragmatic and simple language but that doesn't
> mean that nothing should be changed ever.
PHP strength (IMHO) is it's simple and clear syntax, which allows people who
come from background in other programming languages can quickly recognize and
get used to. Creating confusing alternate syntaxes will bring us ever closer
to Perl 6 where there are dozens of way to do the same thing. The end results
in a confusing and hard to read/write language that all but the most
dedicated of users refuse to use.
> I don't want to break existing programs. And I don't care about range()
> (or even list() too much for that matter), I just recognize the fact the
> I'm using a lot of array() and it is both unnecessarily hard to write
> _and_ read.
That's bull, 5 characters is hard to write? If anything those 5 characters
make it absolutely clear to ANYONE that the data is an array and not an
object or a string or some other type. When I first saw the syntax is took me
a few seconds to realize what it does and the problem would only be
compounded when the code is found within an pre-existing complex script.
Ilia
Antony Dovgal
Christian Schneider <csch...@cschneid.com> wrote:
> I'm just trying to improve PHP. And I write _a lot_ of PHP code, so I
> have some idea about where the syntax could be improved IMHO.
changing the syntax is not the best way imho.
> PHP is a mix of C, Perl and other styles anyway, why deny it? It's
> strength is that it's a pragmatic and simple language but that doesn't
> mean that nothing should be changed ever.
because PHP is PHP.
in C you can use assembler code insertions, but it doesn't mean, that PHP's strength should be powered by allowing assembler insertions.
if in Python you can create new array, using $a = [];, it doesn't mean, that PHP should be able to do it in the same way.
> I don't want to break existing programs. And I don't care about range()
> (or even list() too much for that matter), I just recognize the fact the
> I'm using a lot of array() and it is both unnecessarily hard to write
> _and_ read.
> Saying that array() works well and [] is incomprehensible just does not
> match my experience. Both for myself (some years of programming
> experience) and for newbies. I saw no difference teaching people to
> initialize an array with array() or []. Someone new to programming has
> to memorize that he has to write $a = array() (and not $a = new array()
> for example) anyway, $a = [] would be just as easy IMHO.
this is very confusing way to improve PHP.
you will type 2 symbols instead of 7, but you forget, that you use almost same syntax for indexing arrays.
do you agree, that $a[] = ''; and $a = []; look almost similar for newbies?
> > any reasons to change such fundamental things just because version number
> > changes from 4 to 5.
>
> So why was the whole private/public/static/throw/catch thing introduced?
> Following your logic people who want this should use Java. I'm much
> more worried about code getting unreadable because of these extensions
> actually. It turned PHP into a much more complex language but since it
> is all optional I don't mind. But to deny some simple (and backward
> compatible) syntactic sugar to people who just want an easy to use
> language seems missing the point to me.
you're misrepresenting my words.
PHP didn't have some kind of private/public/static/throw/catch before.
and you're trying to invent new kind of wheel, 'cause you think common model of wheel is "ugly".
> I like some of the Python syntax. But some of it is cumbersome. Same
> with PHP. But I think PHP is closer to what I want so what's wrong with
> trying to improve it where it's possible (and easily done)?
agree, and you can easily make PHP code not readable with such improvements.
again, I can't understand why PHP should have another way of creating new arrays.
there are so many things you can improve in PHP - why did you choose to change the syntax?
so, I'm still strongly against such improvements.
---
WBR,
Antony Dovgal aka tony2001
tony...@phpclub.net
--
Rasmus Lerdorf
> > strength is that it's a pragmatic and simple language but that doesn't
> > mean that nothing should be changed ever.
>
> come from background in other programming languages can quickly recognize and
> get used to. Creating confusing alternate syntaxes will bring us ever closer
> to Perl 6 where there are dozens of way to do the same thing. The end results
> in a confusing and hard to read/write language that all but the most
> dedicated of users refuse to use.
Well, like I said before, I am not sure this is a clear case of that. I'm
probably the biggest defender around of the no-magic rule, but [] does
imply something array-related to most people, so I think the magic part is
much smaller than in other proposals we have seen.
> That's bull, 5 characters is hard to write? If anything those 5 characters
> make it absolutely clear to ANYONE that the data is an array and not an
> object or a string or some other type. When I first saw the syntax is took me
> a few seconds to realize what it does and the problem would only be
> compounded when the code is found within an pre-existing complex script.
I do agree that [1,2,3] is not easier to read than array(1,2,3), but I
don't think there is a huge difference between the two. I guess we could
sample a few newbie users to see what they think $a = [1,2,3]; would do.
Of course, then people are going to try to do $a = $b[1,2,3]; and then we
are all messed up.
-Rasmus
Ilia Alshanetsky
> Well, like I said before, I am not sure this is a clear case of that. I'm
> probably the biggest defender around of the no-magic rule, but [] does
> imply something array-related to most people, so I think the magic part is
> much smaller than in other proposals we have seen.
Right now [] could either be an array element or an offset. Now it can either
be an array element or a string offset or an attempt to create a new array.
Individually it may be fine, but I am certain we'll end up with bug reports
of people trying to do $a = $b[1,2,3]; (copied from your resonse ;) ) and
similar. Of course someone would then want to do $a[1,2,3] = [3,4,5]; and
we're happily on our road to obfuscation.
I mean c'mon, is 5 characters that much of a problem and is absolute code
clarity not worth those 5 characters? Character efficiency is done in Perl,
where you can do things like ~= and @_, but that makes Perl code naturally
obfuscated and I do not think that's a good way to go.
Ilia
Andi Gutmans
I don't believe in saving characters. You probably know that I tend to
prefer looooooong meaningful names and not have all sorts of magic. I think
in this case, it's not a matter of saving the typing as it looks much
better and IMO is more intuitive.
Anyway, it's no biggy and if most people here think it shouldn't be added
then that's fine with me.
Andi
Jani Taskinen
>I do not like the new syntax at all. If anything it seems rather unnatural and
>what do you save, typing of 5 characters that makes it clear that this is an
>array to even the most novice of users? It certainly not going to make the
>code any faster and if anything will only add confusion.
>
>Firm -1.
There's enough magic already..I could say +1 if magic_quotes_*
is removed and everything is made case-sensitive first. :)
--Jani
Ford, Mike [LSS]
wisdom:
> On November 5, 2003 10:34 am, Christian Schneider wrote:
>> PHP is a mix of C, Perl and other styles anyway, why deny it?
>> It's strength is that it's a pragmatic and simple language
>> but that doesn't mean that nothing should be changed ever.
>
> PHP strength (IMHO) is it's simple and clear syntax, which
> allows people who
> come from background in other programming languages can
> quickly recognize and
> get used to. Creating confusing alternate syntaxes will bring
> us ever closer
> to Perl 6 where there are dozens of way to do the same thing.
> The end results
> in a confusing and hard to read/write language that all but
> the most dedicated of users refuse to use.
Yes, I agree with this, but I also think that a modicum of alternatives in a
few strategically chosen places also makes a language easier to use for
people coming from different backgrounds and with different style prejudices
-- or even just with differently-built brains! A prime example of this is
the "alternative structure syntax" -- as a confirmed and long-time hater of
the curly-brackets-for-everything style (as a result of many years of using
it in B, c, JavaScript and others), I was overjoyed to discover the
alternative :-syntax in PHP and use it exclusively in all my scripts.
Contrariwise, there are some features in (and not in!) PHP that I think are
pretty silly, but some of its prime maintainers defend to the death -- well,
that's their opinion and I would defend to the death their right to have it,
whilst nevertheless continuing to disagree with them.
>> I don't want to break existing programs. And I don't care
>> about range() (or even list() too much for that matter), I
>> just recognize the fact the I'm using a lot of array() and it
>> is both unnecessarily hard to write _and_ read.
>
> That's bull, 5 characters is hard to write? If anything those
> 5 characters make it absolutely clear to ANYONE that the data
> is an array
> and not an
> object or a string or some other type. When I first saw the
> syntax is took me
> a few seconds to realize what it does and the problem would
> only be compounded when the code is found within an
> pre-existing
> complex script.
Well, my view on that is the exact contrary -- I find the 5 letters in
question and their associated parentheses easy to lose in the surrounding
and very similar code, whereas the [] syntax both stands out much better
against surrounding noise and is, for me, more intuitive. I think there's
room for both -- I and all the other +1s would no doubt enthusiastically
switch over wholesale to [], whilst you and the other -1s would stick with
array(). I would have no problem with that, and to me it would be an
advantage of the language that it supports such choice.
Cheers!
Mike
--
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
Christian Schneider
> I don't believe in saving characters.
Agreed, it's not about saving characters (only).
> Anyway, it's no biggy and if most people here think it shouldn't be
> added then that's fine with me.
Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
couldn't figure out if they are pro or con (-:C
- Chris
Christian Schneider
> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
$a = array(array(1,2,3),array(1=>array(1,3,2,2),
"a"=>array(array(1,2,3,4),4,array(1,2)));
What was your point again? ;-)
Marco Tabini
>
> On Nov 5, 2003, at 11:52 AM, Marco Tabini wrote:
>
>> But isn't there a big difference between an assignment and a reference?
>> I, for one, think that language constructs should be as univocal as
>> possible in order to minimize confusion, lest we end up having to read
>> something like:
>>
>> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>>
>> in there... :-)
>
>
> is that any less clear than
>
> $a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
> array(array(1,2,3,4), 4, array(1,2)));
>
> Both examples can be made crystal clear with appropriate whitespace.
Except that the word array provides a nice break *and* it does not
create confusion in the use of a language construct (see my previous msgs).
Cheers,
Marco
Ford, Mike [LSS]
wisdom:
> I mean c'mon, is 5 characters that much of a problem and is
> absolute code clarity not worth those 5 characters? Character
> efficiency is done in Perl, where you can do things like ~=
> and @_, but that makes Perl code naturally obfuscated and I do
> not think that's a good way to go.
I don't think the number of characters is the main issue here -- it's about
having a *nicer* set of characters. Personally, I'd be still be in favour
(although not quite as much) if the proposed syntax were [[[1,2,3]]] -- for
me, it's about having a syntax that shouts *ARRAY* rather than whispers it.
(Although the reduction in characters is handy -- particularly in a
construct like ['foo' => ['bar'=>'on', 'baz'=>[2,3,5,7]],
'bedrock'=>['rubble'=>['barney', 'betty'], 'flintstone'=>['fred',
'wilma']]].)
Cheers!
Mike
--
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
Ford, Mike [LSS]
> Christian Schneider wrote:
>> Marco Tabini wrote:
>>
>>> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>>
>>
>> $a = array(array(1,2,3),array(1=>array(1,3,2,2),
>> "a"=>array(array(1,2,3,4),4,array(1,2)));
>>
>
> Besides my previous points, something even more abominable:
>
> $a = [1,2,$b[11]];
>
> Is that confusing enough for you? ;-)
What's confusing about it?
Ford, Mike [LSS]
>
> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>
> I don't know about you, but I can't even begin to count the
> brackets in there... :-)
At quick glance says it looks unbalanced. A count shows why: 7 [s and 6 ]s
;)
I couldn't begin to suggest whether you left out a ] or have one too many [,
or where...!!
Marco Tabini
> On 05 November 2003 17:06, Marco Tabini contributed these pearls of wisdom:
>
>
>>Christian Schneider wrote:
>>
>>>Marco Tabini wrote:
>>>
>>>
>>>
>>>
>>>"a"=>array(array(1,2,3,4),4,array(1,2)));
>>>
>>
>>Besides my previous points, something even more abominable:
>>
>>$a = [1,2,$b[11]];
>>
>>Is that confusing enough for you? ;-)
>
>
> What's confusing about it?
>
The fact that $b[11] references an item of an array, while [1,2,$b[11]]
assigns values to the array $a. The fact that you (and, probably, most
of us) can't tell right off the bat is a clear sign that this is a bad
idea, because it's ambiguous and confusing.
The same line using the current syntax, btw, would have looked like this:
$a = array (1,3,$b[11]);
As you can see the ambiguity is gone--square brackets are used for one
purpose and nothing else.
Cheers,
Marco
Ilia Alshanetsky
> I don't think the number of characters is the main issue here -- it's about
> having a *nicer* set of characters. Personally, I'd be still be in favour
> (although not quite as much) if the proposed syntax were [[[1,2,3]]] -- for
> me, it's about having a syntax that shouts *ARRAY* rather than whispers it.
> (Although the reduction in characters is handy -- particularly in a
> construct like ['foo' => ['bar'=>'on', 'baz'=>[2,3,5,7]],
> 'bedrock'=>['rubble'=>['barney', 'betty'], 'flintstone'=>['fred',
> 'wilma']]].)
Sure, now support one of your string array keys/values contains a [ or ]
character. That would wreak havoc with the readability of the code.
Having 2 separate syntaxes would mean that some devs would use one format and
the other another. And eventually you'll end up with the same code written in
2 separate ways within the same script/application because 1 part (older?)
was written in 1 way and the other (newer) written in another. This makes the
entire application more difficult to understand and since many people learn
through modifying scripts you'll create more barriers to entry for new users.
A few more examples how this will cause problems:
$a[1,2,3,4][] = [5,6,7,8][2];
Ilia
Steph
I think it would be cool to have the cleaner alternative syntax; I think I'd
use it *in some situations and not others*, and I think that that in itself
would make my code virtually unmaintainable by anyone else.
As Andi originally said, having more than one way to do things isn't always
a good thing.
Add me to the -1 list. Even tho' it's a cool idea.
- Steph
> -----Original Message-----
> From: Christian Schneider [mailto:csch...@cschneid.com]
> Sent: 04 November 2003 23:33
> To: inte...@lists.php.net
> Subject: [PHP-DEV] Proposal: Array syntax
>
>
> I propose to add an alternative (backward compatible) short array
> creation syntax:
> $a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
>
> It can also be used in function calls:
> img(['src' => "logo.gif", 'alt' => "Logo"]);
>
> Reason behind this change: Arrays are used a lot and should therefore
> have as little syntactic overhead as possible. And I think the short
> syntax is also easier to read and write.
>
> A patch for the parser is trivial and is attached for Zend2.
>
> Note: I checked the newsgroup archive but couldn't find a discussion
> about this. After not hearing back about my proposed enhancement to
> debug_backtrace() and the dangling comma for function call parameters
> being rejected I wonder if I'm using the right mailing list for this :-)
>
> - Chris
>
--
Andi Gutmans
>On Nov 5, 2003, at 11:52 AM, Marco Tabini wrote:
>>But isn't there a big difference between an assignment and a reference?
>>I, for one, think that language constructs should be as univocal as
>>possible in order to minimize confusion, lest we end up having to read
>>something like:
>>
>>$a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>>
>>I don't know about you, but I can't even begin to count the brackets in
>>there... :-)
>
>is that any less clear than
>
>$a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
>array(array(1,2,3,4), 4, array(1,2)));
>
>Both examples can be made crystal clear with appropriate whitespace.
I agree with that.
Andi
Romans Malinovskis
Think backwards.. Will you be able to convince
any perl/python/javascript developer to use
array(), list(), range() structs?
r
> $a = [1,2,$b[11]];
>
> Is that confusing enough for you? ;-)
>
>
> Mt.
Marco Tabini
> Think backwards.. Will you be able to convince
> any perl/python/javascript developer to use
> array(), list(), range() structs?
>
I really don't think this needs to be a concern. You can't be everything
to all people.
Mt.
Derick Rethans
> Andi Gutmans wrote:
> > I don't believe in saving characters.
>
> Agreed, it's not about saving characters (only).
>
> > Anyway, it's no biggy and if most people here think it shouldn't be
> > added then that's fine with me.
>
> Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
> couldn't figure out if they are pro or con (-:C
Do you think your vote counts? :)
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-------------------------------------------------------------------------
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/
-------------------------------------------------------------------------
--
George Schlossnagle
On Nov 5, 2003, at 12:33 PM, Derick Rethans wrote:
> On Wed, 5 Nov 2003, Christian Schneider wrote:
>
>> Andi Gutmans wrote:
>>> I don't believe in saving characters.
>>
>> Agreed, it's not about saving characters (only).
>>
>>> Anyway, it's no biggy and if most people here think it shouldn't be
>>> added then that's fine with me.
>>
>> Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
>> couldn't figure out if they are pro or con (-:C
>
> Do you think your vote counts? :)
Not that mine necessarily does, but I'm -1 for alternative syntaxes.
Andrey Hristov
>> Andi Gutmans wrote:
>> > I don't believe in saving characters.
>>
>> Agreed, it's not about saving characters (only).
>>
>
>
>>> > Anyway, it's no biggy and if most people here think it shouldn't be
>>> > added then that's fine with me.
>>
>>
>>
>> Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
>> couldn't figure out if they are pro or con (-:C
>
>
The devs are mostly at the conference now. I think it is easy to discuss.
I won't be surprised if cons after that are more than pros.
One more thing, I think that not PHP but another scripting language is
famous with "There is more than one way to do it!".
Andrey
Rasmus Lerdorf
> Andi Gutmans wrote:
> > I don't believe in saving characters.
>
> Agreed, it's not about saving characters (only).
>
> > Anyway, it's no biggy and if most people here think it shouldn't be
> > added then that's fine with me.
>
> Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
> couldn't figure out if they are pro or con (-:C
In case it wasn't clear, I am a -0 on this. I don't mind the syntax, but
having two different syntaxes is the big problem here.
-Rasmus
Edin Kadribasic
On Wednesday, Nov 5, 2003, at 17:48 Europe/Copenhagen, Andi Gutmans
wrote:
> Anyway, it's no biggy and if most people here think it shouldn't be
> added then that's fine with me.
I like the new syntax proposal, especially when passing arrays as
function parameters.
+1 here.
Edin
Moriyoshi Koizumi
> I do agree that [1,2,3] is not easier to read than array(1,2,3), but I
> don't think there is a huge difference between the two. I guess we could
> sample a few newbie users to see what they think $a = [1,2,3]; would do.
> Of course, then people are going to try to do $a = $b[1,2,3]; and then we
> are all messed up.
Yeah, it will mess us up all. I did a quick hack to realise this
feature. The patch is pasted below.
<?php
$a = array('ArrayArray' => 'nay');
var_dump($a[[0].[0]]);
?>
Indeed this works :) I'm not much interested in this kind of discussion
though.
Moriyoshi
Index: Zend/zend_language_parser.y
===================================================================
RCS file: /repository/Zend/Attic/zend_language_parser.y,v
retrieving revision 1.23
diff -u -r1.23 zend_language_parser.y
--- Zend/zend_language_parser.y 4 Aug 2002 06:39:44 -0000 1.23
+++ Zend/zend_language_parser.y 5 Nov 2003 17:42:40 -0000
@@ -484,6 +484,7 @@
| '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } expr { zend_do_end
_silence(&$1 TSRMLS_CC); $$ = $3; }
| scalar { $$ = $1; }
| T_ARRAY '(' array_pair_list ')' { $$ = $3; }
+ | '[' array_pair_list ']' { $$ = $2; }
| '`' encaps_list '`' { zend_do_shell_exec(&$$, &$2 TS
RMLS_CC); }
| T_PRINT expr { zend_do_print(&$$, &$2 TSRMLS_CC); }
;
Romans Malinovskis <romans@void.lv>(by way of Romans Malinovskis)
> I won't be surprised if cons after that are more than pros.
I think end-user / newbie votes should be rather considered than dev's since
they are ones who will be learning and getting used to this syntax. So why
don't place a pool on some php developer website? That would be more correct
to php real users.
r
Jani Taskinen
>At 11:58 AM 11/5/2003 -0500, George Schlossnagle wrote:
>
>>On Nov 5, 2003, at 11:52 AM, Marco Tabini wrote:
>>>But isn't there a big difference between an assignment and a reference?
>>>I, for one, think that language constructs should be as univocal as
>>>possible in order to minimize confusion, lest we end up having to read
>>>something like:
>>>
>>>$a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>>>
>>>I don't know about you, but I can't even begin to count the brackets in
>>>there... :-)
>>
>>is that any less clear than
>>
>>$a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
>>array(array(1,2,3,4), 4, array(1,2)));
>>
>>Both examples can be made crystal clear with appropriate whitespace.
>
>I agree with that.
So it's gonna be the pythonized version? ie. if there is no
appropriate whitespace -> parse error? :)
--Jani
Jaap van Ganswijk
>Very cool.
>
>How about supporting .. syntax, btw. as in [1..3] or ["a".."z"]? Might no be the worth, just thinking out loud ;)
I'm also in favor of a shorter notation for array() and list().
In fact this also helps to ease the problem I have
with 'foreach ($A as $I=>$d)', because it would
then be possible to write: while ([$i,$d]=each($A)).
It's still not as short as I'd like it to be:
'while ($i=>$d in $A)', but it's already a lot
better.
I'd also like to see ranges supported and propose
to add notations for inclusive and non-inclusive
ranges as:
1..3 inclusive at both ends so equal to 1,2,3
1.<3 non inclusive at the end so equal to 1,2
1>.3 non inclusive at the beginning so equal to 2,3
1><3 non inclusive at both ends so equal to 2
Of course generally only the first two variations
are being used.
(Please note that this syntax conflicts slightly
with the syntax of floating point numbers and
compares. Perhaps it's solvable by scanning '..',
'.<', '>.' and '><' as tokens first and not
allowing ranges with floating point numbers
anyway.)
By the way, Python has three 'group' notations:
[] for a list
{} for a dictionary
() for a tuple
Very confusing (and one of the reasons I prefer PHP
over Python ;-), and I agree with Rasmus that at least
here the symbols no longer make clear what is being
meant, but I think that just [] for the values in an
array is very intuitive because the same symbols are
being used to add the index of an array. (But {}
from the set notion in mathematics would be fine too,
I think).
By the way, don't forget to allow a comma at the end
of a list: 1,2,3,
This especially makes sense when the elements are
listed each on a seperate line:
1,
2,
3,
Greetings,
Jaap
>Christian Schneider wrote:
>>I propose to add an alternative (backward compatible) short array creation syntax:
>>$a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
>>It can also be used in function calls:
>>img(['src' => "logo.gif", 'alt' => "Logo"]);
>>Reason behind this change: Arrays are used a lot and should therefore have as little syntactic overhead as possible. And I think the short syntax is also easier to read and write.
>>A patch for the parser is trivial and is attached for Zend2.
>>Note: I checked the newsgroup archive but couldn't find a discussion about this. After not hearing back about my proposed enhancement to debug_backtrace() and the dangling comma for function call parameters being rejected I wonder if I'm using the right mailing list for this :-)
>>- Chris
>>
>>------------------------------------------------------------------------
>>Index: Zend/zend_language_parser.y
>>===================================================================
>>RCS file: /repository/ZendEngine2/zend_language_parser.y,v
>>retrieving revision 1.127
>>diff -u -r1.127 zend_language_parser.y
>>--- Zend/zend_language_parser.y 19 Oct 2003 08:38:48 -0000 1.127
>>+++ Zend/zend_language_parser.y 4 Nov 2003 23:32:12 -0000
>>@@ -581,6 +581,7 @@
>> | '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } expr { zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }
>> | scalar { $$ = $1; }
>> | T_ARRAY '(' array_pair_list ')' { $$ = $3; }
>>+ | '[' array_pair_list ']' { $$ = $2; }
>> | '`' encaps_list '`' { zend_do_shell_exec(&$$, &$2 TSRMLS_CC); }
>> | T_PRINT expr { zend_do_print(&$$, &$2 TSRMLS_CC); }
>> ;
>
Michael Walter
>>>
>>> Is that confusing enough for you? ;-)
>>
>>
>>
>>
>
> The fact that $b[11] references an item of an array, while [1,2,$b[11]]
> assigns values to the array $a. The fact that you (and, probably, most
> of us) can't tell right off the bat is a clear sign that this is a bad
> idea, because it's ambiguous and confusing.
>
> The same line using the current syntax, btw, would have looked like this:
>
> $a = array (1,3,$b[11]);
comparison with the rather verbose array() version (same thing with the
swap, btw).
BTW, remember the alternative range syntax [a..b] I mentioned before? If
you consider Markus Boegers (sp?) iterators extension, wouldn't it be
top cool to have [a..] syntax, too (yielding an iterator)? And have
versions of map/filter/reduce support iterators, too? :) Well, just
thinking out loud, you remember ;)
> As you can see the ambiguity is gone--square brackets are used for one
> purpose and nothing else.
Actually, do you realize that you use () both for "grouping" and for
application? I can't see anything wrong with using square brackets for
array element access and array creation, to be honest.
Cheers,
Michael
Cesare D'Amico
> > The devs are mostly at the conference now. I think it is easy to
> > discuss. I won't be surprised if cons after that are more than
> > pros.
>
> I think end-user / newbie votes should be rather considered than
> dev's since they are ones who will be learning and getting used to
> this syntax. So why don't place a pool on some php developer website?
> That would be more correct to php real users.
I don't think so. Dev's have an understanding of php as a whole that=20
most people haven't, so they are more clever in judging new features.
Moreover, i agree with Steph:
> I think it would be cool to have the cleaner alternative syntax; I
> think I'd use it *in some situations and not others*, and I think that
> that in itself would make my code virtually unmaintainable by anyone
> else.
This is really a good point to me.
Ciao
ce
=2D-=20
Cesare D'Amico - http://www.phpday.it
"E` un'emergenza!!! Dovrei fare questo-e-questaltro ma non=20
posso perche' la mia testa e` piena di segatura e criceti!!!"
-- un utente [ http://www.soft-land.org/storie/ ]
Andrey Hristov
>At 2003-11-05 09:59 +0100, Michael Walter wrote:
>
>
>>Very cool.
>>
>>How about supporting .. syntax, btw. as in [1..3] or ["a".."z"]? Might no be the worth, just thinking out loud ;)
>>
>>
>
>I'm also in favor of a shorter notation for array() and list().
>
>In fact this also helps to ease the problem I have
>with 'foreach ($A as $I=>$d)', because it would
>then be possible to write: while ([$i,$d]=each($A)).
>
>
Do you know that while(list(..,..) = each($ar))
is kinda "deprecated". You should consider using
foreach() which is clearer and the fastest way to
traverse an array. while() + each() + list() is the
old way (evermore, you have not to forget to reset()
your array before the traversal - foreach() does not
need this step).
Andrey
>It's still not as short as I'd like it to be:
>'while ($i=>$d in $A)', but it's already a lot
>better.
>
>I'd also like to see ranges supported and propose
>to add notations for inclusive and non-inclusive
>ranges as:
>1..3 inclusive at both ends so equal to 1,2,3
>
>
>1.<3 non inclusive at the end so equal to 1,2
>1>.3 non inclusive at the beginning so equal to 2,3
>1><3 non inclusive at both ends so equal to 2
>
>
Use the range() function. PHP is more close to C than to
Pascal in my opinion. The language should be simple the
standard library should be rich (IMO).
Andrey
Marco Tabini
>>>> $a = [1,2,$b[11]];
>>>>
>>>> Is that confusing enough for you? ;-)
>>>
>>>
>>>
>>>
>>> What's confusing about it?
>>>
>>
>> The fact that $b[11] references an item of an array, while
>> [1,2,$b[11]] assigns values to the array $a. The fact that you (and,
>> probably, most of us) can't tell right off the bat is a clear sign
>> that this is a bad idea, because it's ambiguous and confusing.
>>
>> The same line using the current syntax, btw, would have looked like this:
>>
>> $a = array (1,3,$b[11]);
>
> Actually, $a = [1,2,$b[11]] would be amazingly clear and expressive in
> comparison with the rather verbose array() version (same thing with the
> swap, btw).
I guess we'll have to agree to disagree :)
$a = [1,2,$b[11]] is semantically inconsistent.
>> As you can see the ambiguity is gone--square brackets are used for one
>> purpose and nothing else.
>
> Actually, do you realize that you use () both for "grouping" and for
> application? I can't see anything wrong with using square brackets for
> array element access and array creation, to be honest.
Actually, no, I don't. I'm not sure what "grouping" and "application"
mean...
Mt.
Michael Walter
>>with PHP. But I think PHP is closer to what I want so what's wrong with
>>trying to improve it where it's possible (and easily done)?
>
>
> agree, and you can easily make PHP code not readable with such improvements.
> again, I can't understand why PHP should have another way of creating new arrays.
> there are so many things you can improve in PHP - why did you choose to change the syntax?
Cause array() really is used very often, and could be made much more
"pretty" (read: readable, expressive) with [].
Cheers,
Michael
PS: there was static without the keyword in ZE1.
Michael Walter
Yeah, I agree to disagree on that one, too :)
>> Actually, do you realize that you use () both for "grouping" and for
>> application? I can't see anything wrong with using square brackets for
>> array element access and array creation, to be honest.
>
>
> Actually, no, I don't. I'm not sure what "grouping" and "application"
> mean...
$a*(1+2) vs. $a(1+2)
"Grouping" (not really a good term, I'm sorry) in the sense of
determining the order of evaluation.
"Application" being normal function application (function call).
Cheers,
Michael
George Schlossnagle
On Nov 5, 2003, at 12:54 PM, Jani Taskinen wrote:
> On Wed, 5 Nov 2003, Andi Gutmans wrote:
>
>> At 11:58 AM 11/5/2003 -0500, George Schlossnagle wrote:
>>
>>> is that any less clear than
>>>
>>> $a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
>>> array(array(1,2,3,4), 4, array(1,2)));
>>>
>>> Both examples can be made crystal clear with appropriate whitespace.
>>
>> I agree with that.
>
> So it's gonna be the pythonized version? ie. if there is no
> appropriate whitespace -> parse error? :)
The point was that the example was unreadable even if translated
directly into syntactical PHP. To make it 'readable', you need to add
whitespace, which would in fact make either syntax quite readable.
Anything can look like crap if you want it to.
George
George Schlossnagle
On Nov 5, 2003, at 1:29 PM, Marco Tabini wrote:
> $a = [1,2,$b[11]] is semantically inconsistent.
How so? Is
foo(array(1,2));
semantically inconsistent? On one hand () is used with a language
construct (array()), whereas in the other context it indicates
arguments to a function. I think that is what he meant by 'grouping'
and 'application'.
Similar tokens have different syntactical meaning all over the
language. Compare '<<' and '<<<'. To me that is no diffent that
<variable>[] and [].
George (still -1, but because it makes for unmaintainable code, not
because it's hard to read)
David Enderson
guys were generating comments faster than I could read them! lol.
I have used PHP constantly for 2 years. Most of that time has been
spent using arrays very extensively and often as function parameters.
For what my vote is worth, I strongly favor the newly suggested notation
(+1).
I'm not going to try to restate all the pros discussed and address all
the cons. I prefer not to have multiple ways to do things and I found
the list() function to be very counter-intuitive. I was thrilled when
foreach() came out and deprecated while(), list(), each() syntax.
Typing "array()" isn't very many more letters, that's true, but I type
it A LOT! lol. I sometimes use it as a parameter, and VERY often have
to use it to initialize variables before doing array_push() or setting
array items inside loops. Using: $a =3D []; would be wonderful and much
less clunky.
As far as extending the syntax to the list() command...well...I would
prefer to just find a way to deprecate it entirely, but that is probably
not possible. So I guess even though it would seem to make sense I
would have to vote against that because it SETS the values of its
"parameters".
Yes, it may be the way another language does it. All languages borrow
from others, as recent discussions regarding foreach() and {}
demonstrate.
I believe the ultimate goal of PHP is to have a "quick and dirty"
language that is easy to read, use, and learn. While Rasmus's comment
about no-magic made me stop and examine this for a while, I believe it
fits all those goals nicely and is an elegant reason to make an
exception to the no-magic rule.
No, I don't want to see stuff like:
if ([1][0] =3D=3D 1) {
but as someone pointed out, you can make anything look nasty in C-syntax
derived languages.
--David
-----=3D+=3D-----
David Enderson
Programmer
Digital IMS
Shane Caraveo
+1 for the [] syntax. I also feel it's much more intuitive. Calling
(what looks like) a function to make an array seems plain silly to me.
Shane
Michael Walter
> George Schlossnagle wrote:
>
>>
>> On Nov 5, 2003, at 1:29 PM, Marco Tabini wrote:
>>
>>> $a = [1,2,$b[11]] is semantically inconsistent.
>>
>>
>>
>> How so? Is
>>
>
Not really understandable, though.
>
>> foo(array(1,2));
>>
>> semantically inconsistent? On one hand () is used with a language
>> construct (array()), whereas in the other context it indicates
>> arguments to a function. I think that is what he meant by 'grouping'
>> and 'application'.
>>
>
> Actually, I think it meant something else. In any case, semantically you
> can still think of array() as a function (until you throw in key
> declarations, of course ;) )
Yup, I told you I meant something different (although on the same line
of reasoning). I think you misunderstand "semantics", anyway. You should
not think of array() as a function, as basically everything else except
to the syntax is different to "real" functions, consider
call_user_func('array', 1, 2, 3) or array_map('array', array(1, 2, 3),
array("Foo", "Bar", "Baz"));
How much better would look map('array', [1..3], ["Foo", "Bar", "Baz"]);
anyway.. (although we really should not argue about that, as it's simply
taste).
>> Similar tokens have different syntactical meaning all over the
>> language. Compare '<<' and '<<<'. To me that is no diffent that
>> <variable>[] and [].
>
>
> Again, that's not a good reason to introduce more.
That is a statement backed up by good argumentation. :)
Greg MacLellan
> On Wed, 5 Nov 2003, Christian Schneider wrote:
>
>>Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
>>couldn't figure out if they are pro or con (-:C
>
>
> In case it wasn't clear, I am a -0 on this. I don't mind the syntax, but
> having two different syntaxes is the big problem here.
>
That's the way I think, too. It's not really that bad, except there's
already a way to define arrays (array()). There's really no point in
adding a second way that doesn't really bring any benefits besides
slightly shorter syntax, and it's totally unfeasable to remove the
array() syntax.
Also, the fact that [] are used for array indexes means it's more
confusing when they're also used in a very similar context of defining
the actual array.
Marco's example
$a = [1,2,$b[11]];
I think best illustrates this point.
-1 on this.
--
Greg MacLellan
Robert Cummings
>
> I believe the ultimate goal of PHP is to have a "quick and dirty"
> language that is easy to read, use, and learn. While Rasmus's comment
I complete disagree with the "quick and dirty" statement. Maybe at one
time, but I think a lot of effort has gone into PHP in recent years to
entertain consistency and quality. As for the new syntax, *shrug*, I'm
happy with the array() function syntax, but could care less if it were
implemented. I guess I'm -0 :)
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
David Enderson
And I don't agree with it either. I like quick, but I don't like dirty.
I just thought from what I'd read on this list over the last year that
it was a goal. You may be correct that I misinterpreted the current
goals of the language, and I'll be happy if you are right. :-)
--David
> -----Original Message-----
> From: Robert Cummings [mailto:rob...@interjinn.com]=20
> Sent: Wednesday, November 05, 2003 3:09 PM
> To: David Enderson
> Cc: inte...@lists.php.net
> Subject: RE: [PHP-DEV] Proposal: Array syntax
>=20
>=20
> On Wed, 2003-11-05 at 14:03, David Enderson wrote:
> >=20
> > I believe the ultimate goal of PHP is to have a "quick and dirty"=20
> > language that is easy to read, use, and learn. While=20
> Rasmus's comment
>=20
> I complete disagree with the "quick and dirty" statement.=20
> Maybe at one time, but I think a lot of effort has gone into=20
> PHP in recent years to entertain consistency and quality. As=20
> for the new syntax, *shrug*, I'm happy with the array()=20
> function syntax, but could care less if it were implemented.=20
> I guess I'm -0 :)
>=20
> Cheers,
> Rob.
> --=20
> .------------------------------------------------------------.
> | InterJinn Application Framework - http://www.interjinn.com |
> :------------------------------------------------------------:
> | An application and templating framework for PHP. Boasting | a=20
> | powerful, scalable system for accessing system services | such as=20
> | forms, properties, sessions, and caches. InterJinn |
> | also provides an extremely flexible architecture for |
> | creating re-usable components quickly and easily. |
> `------------------------------------------------------------'
>=20
Sara Golemon
I'm -1 on this syntax.
It's Perlish and ugly. It is *not* PHP syntax.
-Sara
George Schlossnagle
On Nov 5, 2003, at 5:41 PM, Sara Golemon wrote:
> FWIW- (And I understand I'm late chiming in on this thread)
>
> I'm -1 on this syntax.
>
> It's Perlish and ugly. It is *not* PHP syntax.
To continue to play devils advocate, I actually find it C-ish and nice:
char foo[] = { "a", "b", "c i told you so"};
George (thinking [] is pretty but disliking alternative syntaxes)