Hi,
I thought I may have brought this up a long time ago but couldn't find anything in the archives.
For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.
So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)
Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.
Andi
Hello Andi,
it is a bit harder to read and not the php way imo.
best regards
marcus
Sunday, February 4, 2007, 8:25:22 AM, you wrote:
Hi,
I thought I may have brought this up a long time ago but couldn't find anything in the archives.
For a long time already I've been thinking about possibly adding a new
syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to do
things, I think it'd look much more elegant especially (but
not only) for nested arrays.
So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)
Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as it's
not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.
Andi
Best regards,
Marcus
Marcus Boerger wrote:
Hello Andi,
it is a bit harder to read and not the php way imo.
I agree with Marcus.
regards,
Lukas
Marcus Boerger wrote:
it is a bit harder to read and not the php way imo.
The PHP way is to steal and borrow from other languages whenever
possible to produce a syntax that is clear and understandable to people
doing web development.
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.
-Rasmus
I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.
it sure acceptable for php users and will never be a conflict to "php way"
php is mean to be used for web pages in the first place, most ppl who
works on web pages have to know what javascript is, so there isn't any
difficulty for ppl to get used to either read or code []
btw, "ppl use json in instead of xml" may (or may not) be a good
example to this topic
phpxcache wrote:
most ppl who works on web pages have to know what javascript
is, so there isn't any difficulty for ppl to get used ...
You give brand new PHP hackers too much credit. Sure professional PHP
developers do have to work with Javascript. But, working on Phorum and
see real users who are trying to hack their way around PHP, I can tell
you, they don't have a clue what they are doing. $a = [1,2,3]; would
not mean jack sqat to those folks. And as stated, finding docs on that
syntax would not be easy. I tried finding the docs on the back tick
syntax the other day and had a hard time. And I know what it does. I
finally had to go look up exec() and hope some good doc writer (thanks,
whoever that was) had linked the back tick syntax there.
-1 for confusing new PHP users.
--
Brian Moon
http://dealnews.com/
It's good to be cheap =)
you, they don't have a clue what they are doing. $a = [1,2,3]; would
not mean jack sqat to those folks. And as stated, finding docs on that
How hard can that be? If one is smart enough to do computer programming,
how hard can it be to know $a=[1,2,3] is an array? Like, what else could
it be?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
you, they don't have a clue what they are doing. $a = [1,2,3]; would
not mean jack sqat to those folks. And as stated, finding docs on thatHow hard can that be? If one is smart enough to do computer programming,
how hard can it be to know $a=[1,2,3] is an array? Like, what else could
it be?
When a new PHP user asks you "What is an array?" you will understand.
Its clear that not all the folks on internals have actually spoken to
the masses of users whose first language is PHP. People don't start
with BASIC and Pascal anymore. That is why it has gotten so popular.
Someone who has never programmed before can pick it up and start hacking.
Don't even try explaining a ternary to them. =)
--
Brian Moon
http://dealnews.com/
It's good to be cheap =)
When a new PHP user asks you "What is an array?" you will understand.
If someone is not familiar with the concept of the array at all, it
doesn't matter if it's written as array(1,2,3) or [1,2,3]. That's not
what we are discussing right now.
Its clear that not all the folks on internals have actually spoken to
the masses of users whose first language is PHP. People don't start
As opposed to you who did, I presume. So, judging from your experience,
how it is different? How explaining array written as [] so much harder
that explaining array written as ()? What exactly constitutes the problem?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
If someone is not familiar with the concept of the array at all, it
doesn't matter if it's written as array(1,2,3) or [1,2,3]. That's not
what we are discussing right now.
My point is that if its written array(1,2,3) that have something to
search for in the docs. The new proposed syntax removes that keyword
that a user can use to find the help they need. As I said, back ticks,
as well as ternary, both suffer from this problem. I see no reason to
add another hurdle for new users when there is no clear advantage to
this new syntax. And, IMO, clear means that a majority of people think
its a no brainer. I would say right now we have nothing of the sort.
--
Brian Moon
http://dealnews.com/
It's good to be cheap =)
I don't buy the "searching docs is easier" argument. There are plenty
of operators and such that are hard to search for.
-Andrei
If someone is not familiar with the concept of the array at all, it
doesn't matter if it's written as array(1,2,3) or [1,2,3]. That's not
what we are discussing right now.My point is that if its written array(1,2,3) that have something to
search for in the docs. The new proposed syntax removes that keyword
that a user can use to find the help they need. As I said, back
ticks, as well as ternary, both suffer from this problem. I see no
reason to add another hurdle for new users when there is no clear
advantage to this new syntax. And, IMO, clear means that a majority
of people think its a no brainer. I would say right now we have
nothing of the sort.--
Brian Moon
http://dealnews.com/
It's good to be cheap =)
Andrei Zmievski wrote:
I don't buy the "searching docs is easier" argument. There are plenty of
operators and such that are hard to search for.
Good point, but, were there pre-existing solutions to those operators
when they were created? I think that is the point that Zeev was making.
We have a way to do this that is 95% the same as this new method. If
this was a new language construct the discussion would be totally different.
--
Brian Moon
http://dealnews.com/
It's good to be cheap =)
I don't buy the "searching docs is easier" argument. There are plenty
of operators and such that are hard to search for.
Yes, and it makes life miserable for some of us...
Is that a good reason to extend that misery to yet another operator?
If the 'array' syntax bugs one that much, write a parser in PHP for
the [] syntax and load the giant arrays with that. :-) :-) :-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Yes, and it makes life miserable for some of us...
Is that a good reason to extend that misery to yet another operator?
Richard, please. This is not advanced OO stuff or anything close.
It's an operator. Give PHP users (even newbies) some credit.
-Andrei
Yes, and it makes life miserable for some of us...
Is that a good reason to extend that misery to yet another operator?
Richard, please. This is not advanced OO stuff or anything close.
It's an operator. Give PHP users (even newbies) some credit.
I was specifically thinking of the sheer number of emails to
PHP-General that would result.
Even if 90% of the newbies "get it" without any research, and 5% more
figure it out from context or reading or trying, there's still a heck
of a lot who will end up posting.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
When a new PHP user asks you "What is an array?" you will
understand.If someone is not familiar with the concept of the array at all, it
doesn't matter if it's written as array(1,2,3) or [1,2,3]. That's not
what we are discussing right now.Its clear that not all the folks on internals have actually spoken
to
the masses of users whose first language is PHP. People don't startAs opposed to you who did, I presume. So, judging from your
experience,
how it is different? How explaining array written as [] so much harder
that explaining array written as ()? What exactly constitutes the
problem?
Here's the difference:
You can Google for 'array' and learn a lot.
If you try to Google for [] you don't learn squat.
Try it and see.
So our 'newbie' at least has a good chance of figuring out array(1, 2,
- on their own. They've got must worse odds of figuring out [1,2,3]
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
how it is different? How explaining array written as [] so much harder
that explaining array written as ()? What exactly constitutes the
problem?Here's the difference:
You can Google for 'array' and learn a lot.
If you try to Google for [] you don't learn squat.
Try it and see.
So our 'newbie' at least has a good chance of figuring out array(1, 2,
- on their own. They've got must worse odds of figuring out [1,2,3]
Ok. So I propose more "searcheable" operators:
let($i, 1) === $i = 1
let($d, add($a, $b, $c)) === $d = $a + $b + $c
call(foo, $arg1, $arg2) === foo($arg1, $arg2)
:-)
Our 'newbie' at least has a good chance of figuring out
$a = [1,2,3] vs. $a = array(1,2,3)
is different than
$a = foobar(1,2,3)
--
Tullio Andreatta
Disclaimer: "Please treat this email message in a reasonable way, or we
might get angry" ( http://www.goldmark.org/jeff/stupid-disclaimers )
Hi.
Our 'newbie' at least has a good chance of figuring out
$a = [1,2,3] vs. $a = array(1,2,3)
is different than
$a = foobar(1,2,3)
I am probably out of my depth here...but I actually find the argument
about wether to introduce this syntax or not, very entertaining...it's a
classic example of human individuality. great really;)
The argument against introducing the new syntax, that says, that it's
less searchable,...well...why not improve the search functionality of
the php-documentation? it would help with all the other operators (and
magic functions and language constructs) if the search-function would
try to match the search-input against operators and constructs, no? I
know that google won't show anything worthwhile when queried about "php
[]" or the like...but...the php-documentation is very good and maybe we
could improve access to it...a newbie could then query all he wants in
the php-doc page. No good?
Lars
you, they don't have a clue what they are doing. $a = [1,2,3]; would
not mean jack sqat to those folks. And as stated, finding docs on thatHow hard can that be? If one is smart enough to do computer programming,
how hard can it be to know $a=[1,2,3] is an array? Like, what else could
it be?
The same argument can be made about how hard it is to understand
$a = array( 1, 2, 3 ).
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. |
`------------------------------------------------------------'
> $a = array( 1, 2, 3 ).
>
It's not hard. I don't think anybody ever argued it's hard to
understand. The argument was it's too verbose once you talk about
multi-dimensional arrays with a lot of sub-arrays containing in turn
even more sub-arrays - entire code becomes packed with repetitions of
"array" word.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
you, they don't have a clue what they are doing. $a = [1,2,3];
would
not mean jack sqat to those folks. And as stated, finding docs on
thatHow hard can that be? If one is smart enough to do computer
programming,
how hard can it be to know $a=[1,2,3] is an array? Like, what else
could
it be?
Looks like a syntax error to me. :-v
I wouldn't know if it was an array or something entirely new.
Could be a random selection from those choices.
Might be an ordered set, though I suppose in PHP that has to be an
array anyway, at least today.
Put it this way: Are you willing to answer EVERY PHP-General question
asking what this is? ;-)
Cuz I'm sure not willing to do it.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Put it this way: Are you willing to answer EVERY PHP-General question
asking what this is? ;-)Cuz I'm sure not willing to do it.
I'm not willing to answer newbie questions on regular basis, but that
has nothing to do with anything - I was unwilling to do it with any
syntax. I just think inability of the users to comprehend a concept such
complicated as two brackets put around the array is grossly exaggerated.
If you figured out how to use <? ?>, you can figure out how to use [] ;)
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hi Andi,
Hi,
I thought I may have brought this up a long time ago but couldn't find anything in the archives.
For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.
I like this syntax, it is clear and easy to write. All other languages
use this syntax already (using either {} or [] but same principle) and
it can be done while keeping the classic array() definition. No need
to mention the numerous requests to add it to php.
--Pierre
I like it :)
+1
Edin
Hi,
I thought I may have brought this up a long time ago but couldn't find
anything in the archives.
For a long time already I've been thinking about possibly adding a new
syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to
do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as
it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but
I'd have to dive a bit deeper.Andi
--
--
Edin Kadribasic, Emini A/S
Symbion Science Park, Fruebjergvej 3
DK-2100 Copenhagen Ø, Denmark
Phone: +45 3917 8335
Mobile: +45 228 226 11
edink@emini.dk
Hi Andi,
I'd like such a syntax enhancement.
These should be the results from the last time the issue was discussed:
http://devzone.zend.com/node/view/id/1474#Heading7
If I remember correct the main issues stated against it were
- it's to perlish
- Without keyword it's hard to find the documentation if you don't know
that syntax
But I would still like having it :-)
johannes
Hi,
I thought I may have brought this up a long time ago but couldn't find anything in the archives.
For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.Andi
Andi Gutmans wrote:
So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
I like this syntax, more conscise but still clear (and well established
in other languages by now).
Two more thoughts (but please don't kill Andi's proposal because of it,
rather dismiss my comments instead ;-)):
- [$a, $b, $c] = ... equivalent to list($a, $b, $c) = ...
- func('foo' => $foo, 'bar' => $bar, ...) equivalent to
func(array('foo' => $foo, 'bar' => $bar, ...), see
http://cschneid.com/php/ for more info
Regards,
- Chris
Andi Gutmans wrote:
So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]I like this syntax, more conscise but still clear (and well
established
in other languages by now).Two more thoughts (but please don't kill Andi's proposal because of
it,
rather dismiss my comments instead ;-)):
- [$a, $b, $c] = ... equivalent to list($a, $b, $c) = ...
Ewwwwwwww!
So now we have an invisible operator with a magical symbol '[' which
sometimes means create an array, but sometimes means to
de-construct an array into individual variables?
That's just disgusting, imho.
-1 !!!
- func('foo' => $foo, 'bar' => $bar, ...) equivalent to
func(array('foo' => $foo, 'bar' => $bar, ...), see
http://cschneid.com/php/ for more info
Again, saving 5 characters just to confuse the hell out of idiots like
me does not seem like a "win" for PHP. :-v
-1
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Richard Lynch wrote:
So now we have an invisible operator with a magical symbol '[' which
sometimes means create an array, but sometimes means to
de-construct an array into individual variables?
The distinction you are making is from an implementation point of view.
From a language users point of view you're just dealing with arrays.
Some people consider the distinction of the two a feature, some consider
it a bug.
That's just disgusting, imho.
To me it makes array usage more orthogonal and hence simpler, but that's
obviously a matter of taste.
What's also beautiful about [] IMHO is the symmetry of the syntax,
list() and array() are asymmetrical which I always found inferior.
- func('foo' => $foo, 'bar' => $bar, ...) equivalent to
func(array('foo' => $foo, 'bar' => $bar, ...), see
http://cschneid.com/php/ for more infoAgain, saving 5 characters just to confuse the hell out of idiots like
me does not seem like a "win" for PHP. :-v
It is NOT about saving characters. If is about less clutter. The more
important saving for us is the removal of an additional pair of parens
which look like line-noise when nested. Funnily enough I forgot the
closing parens of array() in my example above :-)
I agree that our function call syntax is somewhat magical as it
automatically starts and stops the array-composition when encountering
key => value pairs so I wasn't really expecting much love for this from
the list. But one can dream :-)
Anyway, back to the main topic: I'm surprised how much hate a syntactic
change like the one proposed by Andi still provokes nowadays when well
established languages like C, C++, Javascript, Python and Ruby seem to
successfully use [] or {} to construct arrays.
My personal summary of this thread is: We won't have syntactic sugar for
common things like arrays, named parameter emulation and the like ever
because it will be killed by the "we already have a way of doing this"
and the "you cannot look it up" argument. Shame, that would be the tiny
language development I'd personally benefit from.
Regards,
- Chris
Christian Schneider wrote:
My personal summary of this thread is: We won't have syntactic sugar for
common things like arrays, named parameter emulation and the like ever
because it will be killed by the "we already have a way of doing this"
and the "you cannot look it up" argument. Shame, that would be the tiny
language development I'd personally benefit from.
Named parameters is not just syntax sugar, as they would make it
possible to get compiler errors and phpoc support automatically over
having to implement some array based solution to trigger errors and some
other formatting standard for phpdoc. Then again we had this discussion
before as well, and unfortunately it was shot down (IIRC mainly because
people to think that named parameters should then be implemented for all
existing functions as well, which would be too much work .. then again
unicode conversion might (have been) the perfect time to do this).
regards,
Lukas
Lukas Kahwe Smith wrote:
Named parameters is not just syntax sugar, as they would make it
possible to get compiler errors and phpoc support automatically over
having to implement some array based solution to trigger errors and some
Not 'our' way of named parameters where the main feature is the var-args
like behaviour of the parameter list, i.e. being able to pass in
"unknown" parameters. Useful for e.g. HTML generation or DB queries
where you can then map parameter names to HTML attributes or DB fields
respectively. So they are effectively an associative array and syntactic
sugar was good enough for us.
But that's a completely different direction than the and more more
strict way PHP is heading (PPP, typehints, ...) so The List(tm) won't
like ;-)
- Chris
So now we have an invisible operator with a magical symbol '[' which
sometimes means create an array, but sometimes means to
de-construct an array into individual variables?
Yep. We also have an invisible magical operator (), which sometimes
means function definition, sometimes means expression grouping,
sometimes means delimiter, sometimes means function call and sometimes
means regular expression grouping. How do we manage? ;)
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
So now we have an invisible operator with a magical symbol '[' which
sometimes means create an array, but sometimes means to
de-construct an array into individual variables?Yep. We also have an invisible magical operator (), which sometimes
means function definition, sometimes means expression grouping,
sometimes means delimiter, sometimes means function call and sometimes
means regular expression grouping. How do we manage? ;)
How you manage is that a zillion newbies use:
include("foo.inc");
echo("foo.inc");
and they don't even realize that the () doesn't mean what they think
it means, and it "just works" because it's a no-op.
THAT is harder to explain than just about anything in PHP syntax.
How many newbies will be trying:
array[1, 2, 3];
and left scratching their heads when it doesn't work?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
So now we have an invisible operator with a magical symbol '[' which
sometimes means create an array, but sometimes means to
de-construct an array into individual variables?Yep. We also have an invisible magical operator (), which sometimes
means function definition, sometimes means expression grouping,
sometimes means delimiter, sometimes means function call and sometimes
means regular expression grouping. How do we manage? ;)How you manage is that a zillion newbies use:
include("foo.inc");
echo("foo.inc");and they don't even realize that the () doesn't mean what they think
it means, and it "just works" because it's a no-op.
It's not a no-op, I'm sure it actually applies parenthesis precedence on
the expression "foo.inc" :) Personally, I use the parenthesis when using
include and require because I prefer it that way... though I don't doubt
some newbies think it's a function heh.
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. |
`------------------------------------------------------------'
and they don't even realize that the () doesn't mean what they think
it means, and it "just works" because it's a no-op.
() is not a no-op.
return ($a) vs. return $a could cause PHP to corrupt memory and crash :)
Edin
--
Edin Kadribasic, Emini A/S
Symbion Science Park, Fruebjergvej 3
DK-2100 Copenhagen Ø, Denmark
Phone: +45 3917 8335
Mobile: +45 228 226 11
edink@emini.dk
Ewwwwwwww!
So now we have an invisible operator with a magical symbol '[' which
sometimes means create an array, but sometimes means to
de-construct an array into individual variables?That's just disgusting, imho.
-1 !!!
The way I view [] is that it creates an array "context". When the
context is an RHS, it instantiates an array. When it's an LHS, the
context deconstructs the array.
-Andrei
Would this be legal?
function f() {
return [ 1, 2 ];
}
$x = [ $a, $b ] = f();
In the end, would we have...?
$a = 1;
$b = 2;
$x = array(1,2);
I'm not trying to be positive or negative about the
syntax. I'm just "testing" somewhat edge cases.
- Todd
...
The way I view [] is that it creates an array "context". When the
context is an RHS, it instantiates an array. When it's an LHS, the
context deconstructs the array.-Andrei
Good question. If it's possible to make it behave this way, I don't see
why not. On the other hand, if you take list(), it can't be used in
RHS.
-Andrei
Would this be legal?
function f() {
return [ 1, 2 ];
}$x = [ $a, $b ] = f();
In the end, would we have...?
$a = 1;
$b = 2;
$x = array(1,2);I'm not trying to be positive or negative about the
syntax. I'm just "testing" somewhat edge cases.
- Todd
I would argue that list() (and [] when used like list()) should remain a
terminal expression. Yes it's possible to make it non-terminal, but I
don't like what the resulting syntax winds up looking like.
-Sara
Good question. If it's possible to make it behave this way, I don't see
why not. On the other hand, if you take list(), it can't be used in RHS.-Andrei
Would this be legal?
function f() {
return [ 1, 2 ];
}$x = [ $a, $b ] = f();
In the end, would we have...?
$a = 1;
$b = 2;
$x = array(1,2);I'm not trying to be positive or negative about the
syntax. I'm just "testing" somewhat edge cases.
- Todd
Ewwwwwwww!
So now we have an invisible operator with a magical symbol '[' which
sometimes means create an array, but sometimes means to
de-construct an array into individual variables?That's just disgusting, imho.
-1 !!!
The way I view [] is that it creates an array "context". When the
context is an RHS, it instantiates an array. When it's an LHS, the
context deconstructs the array.
I can 'splain list() to a newbie and get them to understand it as an
array deconstructor function thingie, and usually succeed in one or
two tries to get it into their heads.
I don't think I can do that with [] and LHS and RHS in anything like 2
tries... More like 10 times, probably.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
That's because you wouldn't be using those words with a newbie, if
you are smart. You'd simply say "it works like list() here" and "it
works like array()" here.
-Andrei
Ewwwwwwww!
So now we have an invisible operator with a magical symbol '[' which
sometimes means create an array, but sometimes means to
de-construct an array into individual variables?That's just disgusting, imho.
-1 !!!
The way I view [] is that it creates an array "context". When the
context is an RHS, it instantiates an array. When it's an LHS, the
context deconstructs the array.I can 'splain list() to a newbie and get them to understand it as an
array deconstructor function thingie, and usually succeed in one or
two tries to get it into their heads.I don't think I can do that with [] and LHS and RHS in anything like 2
tries... More like 10 times, probably.--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Hi Andi
function typeHinted([] $array = []) { // type hint array, default to empty one
if(count($array)) {
array_merge($array, ["foo" => []]); // merge $array with
array("foo" => array());
return $array;
}
return []; // empty array
}
typeHinted([1 => [1 => []]]); // array(1 => array(1 => array()));
-1 from me
-Hannes
Hi,
I thought I may have brought this up a long time ago but couldn't find anything in the archives.
For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.Andi
Hannes Magnusson wrote:
typeHinted([1 => [1 => []]]); // array(1 => array(1 => array()));
IMHO the common case would benefit and your pathological example is
unreadable both ways. Personally I'd reformat it to
typeHinted([
1 => [
1 => []
]
]);
resp.
typeHinted(array(
1 => array(
1 => array(),
)
));
or something similar anyway to make them readable. Plus you could still
use array() if you really wanted to.
Regards,
- Chris
Plus you could
still
use array() if you really wanted to.
Yes, but sooner or later I am stuck with somebody else's code who
decided to write the non-array version, and I'm sitting there
wondering what [bleep] this code is doing.
This argument really never holds water.
I don't find that dropping 5 characters increases readability to any
large degree.
If readability of a complex structure is of paramount importance,
proper newlines and indentation are going to be required anyway, and
the 'array' bit is not relevant.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Hi Andi
function typeHinted([] $array = []) { // type hint array, default to empty one
That's a wrong example.
Type hinting should still rely on the literal name:
function typeHinted(Array $myarray=[])
--Pierre
My 2c - unless we also make it behave like a list() when in
assignment context - I think it will confusing.
So I'm +1 if we make it work as both list() and array(), and -1 otherwise.
Zeev
At 09:25 04-02-07, Andi Gutmans wrote:
Hi,
I thought I may have brought this up a long time ago but couldn't
find anything in the archives.
For a long time already I've been thinking about possibly adding a
new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way
to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as
it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but
I'd have to dive a bit deeper.Andi
My 2c - unless we also make it behave like a list() when in
assignment context - I think it will confusing.So I'm +1 if we make it work as both list() and array(), and -1
otherwise.
Can you show by example what this means?
I'm seeing several different things in my head...
I don't like any of them, either. :-v
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
I agree. Syntax is good, if we make it work both ways.
-Andrei
My 2c - unless we also make it behave like a list() when in assignment
context - I think it will confusing.So I'm +1 if we make it work as both list() and array(), and -1
otherwise.Zeev
At 09:25 04-02-07, Andi Gutmans wrote:
Hi,
I thought I may have brought this up a long time ago but couldn't
find anything in the archives.
For a long time already I've been thinking about possibly adding a
new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to
do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as
it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but
I'd have to dive a bit deeper.Andi
I have to second Marcus on this, this new syntax makes things harder
to read. I mean what are you saving here, a few letter?
Ilia
Hi,
I thought I may have brought this up a long time ago but couldn't
find anything in the archives.
For a long time already I've been thinking about possibly adding a
new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way
to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as
it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue
but I'd have to dive a bit deeper.Andi
--
Ilia Alshanetsky
I thought I may have brought this up a long time ago but couldn't find
anything in the archives. For a long time already I've been thinking
about possibly adding a new syntax for array(...) which would be
shorter. I'd suggest [...]. While I am usually not in favor of having
more than one way to do things, I think it'd look much more elegant
especially (but not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :) I think it's not worth doing unless
there's overwhelming support as it's not desperately needed. But I'd
be interested to hear people's thoughts. It seems implementation
shouldn't be an issue but I'd have to dive a bit deeper.
That gets a big -1 from me, unless you misposed this mail and it should
have ended up on internals@perl.org or something ;-)
regards,
Derick
So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
An enthusiastic thumbs-sideways.
I'll probably use this at some point, but not for anything which needs
to be version agnostic.
-Sara
I thought I may have brought this up a long time ago but couldn't find
anything in the archives.
For a long time already I've been thinking about possibly adding a new
syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to
do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as
it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but
I'd have to dive a bit deeper.
I somewhat prefer seeing 'array' there so I know what the [bleep] is
going on, personally.
-0.3
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Andi Gutmans wrote:
Hi,
I thought I may have brought this up a long time ago but couldn't find anything in the archives.
For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.
future:
<?php
$a = [1, 2, 3];
$a[1] = [1];
$a = [1];
[$a] = $a;
$a[] = [];
echo $a.[1]; // not a parse error
?>
now:
<?php
$a = array(1, 2, 3);
$a[1] = array(1);
$a = array(1);
list($a) = $a;
$a[] = array();
echo $a.[1]; // now a parse error
?>
For what it's worth, the examples above show why I'm a strong -1 on this
idea. It introduces the possibility of weird misunderstandings that
just don't exist now, and also introduces a new way to accidentally
break your script that wasn't possible before.
The only way I could see solving this would be:
- [] != list()
- use a[] as in $a = a[1, 2, 3] but then we might as well stick with
array().
Either way, [] is overloaded in the new definition:
- array access
- ArrayAccess object offsetGet/offsetSet
- incremental index ($a[] = 1;)
- array creation
[5) list()]
Whereas now, it is only 3 possible meanings, all of which are consistent
with a few quirks in the ArrayAccess one as of PHP 5.2.
Greg
Hi,
I thought I may have brought this up a long time ago but couldn't find anything in the archives.
For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.
It doesn't look more elegant to me.
-1
--
Wbr,
Antony Dovgal
Andi Gutmans schrieb:
Hi,
I thought I may have brought this up a long time ago but couldn't find anything in the archives.
For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
not only) for nested arrays.So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)Well enough examples given :)
I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.Andi
Well, this discussion is really a stupid discussion. Obviously, there
are some people, who likes this syntax ( in list() and array() form) but
there are some people, who dislike it.
But I have to ask: what's the matter. A good programming language should
not force the developer to program as the language wants. A good
programming language should support the developer in writing code he
likes, the way he likes.
Of course there could be problems with new developers. But the question
is: is this relevant?
- Should php as programming language only provide one syntax only
because new developers could have problems (or not, I don't think, that
would be a great problem, because in other languages, this syntax is
already usable). - Should php only support one syntax so that every code is easier to
maintain (if this is your only problem with foreign code, you are a
really lucky guy!)
It don't think so: PHP is a good language, but writing code in PHP is
sometimes awful. This could be improved by an alternative syntax. This
could help new developers who are coming from another language. This
could make coding funnier for some developers.
So: what's the matter? The idea of [] does not harm existent code.
Everyone who does not like this syntax can avoid it in his code. But
please don't tell others how they have to write their code! Let them write!
Mathias
Mathias Bank wrote:
It don't think so: PHP is a good language, but writing code in PHP is
sometimes awful. This could be improved by an alternative syntax. This
could help new developers who are coming from another language. This
could make coding funnier for some developers.
Alternative syntax is what makes reading someone else's Perl code
"funny" ... ;(
So: what's the matter? The idea of [] does not harm existent code.
Everyone who does not like this syntax can avoid it in his code.
But please don't tell others how they have to write their code!
Let them write!
This violates a simple but important principle:
The burden shall be on the writer, not the readers.
As long as you write code all by yourself and never share it in
any way your argument may hold true. The very second your code
needs to be read or even maintained by others alternative syntax
choices quickly become a nightmare. So you have to agree on one
form or the other and add yet another item to your coding style
rules list. So you even have to bother more about telling
others (or yourself) how to write code than you had to with only
one syntax alternative.
As a matter of taste i do prefer the [] alternative over the
current array()/list() approach. But we can't get rid of array()
or list() any time soon, even if we would decide to deprecate them
now in favor of []. So we're stuck with them and the nicer syntax
does not justify the can of worms opened by introducing an
alternative syntax for an already existing feature.
So if we were designing PHP today i'd be all for [] and [] only,
but as things are my vote is mostly against it even though i sort
of like the syntax.
So from my side a
-0.8
--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com
But I have to ask: what's the matter. A good programming language should
not force the developer to program as the language wants. A good
programming language should support the developer in writing code he
likes, the way he likes.
So, you are new to php internal huh? =)
Seriously, the language can not be adapted to every whim of every
developer. Adding several ways to do things was fine when PHP was a
neat tool to mess around with. Now people's paychecks depend on it.
IMO, it's a slippery slope to just add things because you can.
This could be improved by an alternative syntax.
Ah, but not all see it as an improvement. Peronsally, every time I see
this type of syntax in perl or javascript, I cringe. Luckily I don't do
much perl. When I see it in JS, I change it.
The funny thing is that Andi probably could have just commited this to
the PHP6 tree and made an announcement. There would have been ~4
replies and it would have been over with.
--
Brian Moon
http://dealnews.com/
It's good to be cheap =)
I for one cringe when I see list(), and I'd love to see [$a, $b] =
array(...) become an alternative to that. Can't say I care that much
about an alternative syntax for dealing with array creation, but I
wouldn't mind.
"[]" already suggests "array", and I guess existing developers will have
no problem picking it up. Newbies would bump into the docs just as they
currently bump into the array section.
I don't see how an addition like this could affect people's paychecks.
V
Brian Moon wrote:
But I have to ask: what's the matter. A good programming language
should not force the developer to program as the language wants. A
good programming language should support the developer in writing
code he likes, the way he likes.So, you are new to php internal huh? =)
Seriously, the language can not be adapted to every whim of every
developer. Adding several ways to do things was fine when PHP was a
neat tool to mess around with. Now people's paychecks depend on it.
IMO, it's a slippery slope to just add things because you can.This could be improved by an alternative syntax.
Ah, but not all see it as an improvement. Peronsally, every time I
see this type of syntax in perl or javascript, I cringe. Luckily I
don't do much perl. When I see it in JS, I change it.The funny thing is that Andi probably could have just commited this to
the PHP6 tree and made an announcement. There would have been ~4
replies and it would have been over with.