Hi,
I hear this often by other developers and I tend to agree with them, that arrays are used often, and often nested, so that having a long syntax for array literals tend to produce less legible code than in other scriping languages.
$a = array(array(1,2), array(3,4), 5, 6);
$b = array('a' => 1, 'b' =>2);
We use arrays in our configurations, in passing complex parameters to functions, fetching information from databases, basically everything. So it adds up.
Some frameworks have somewhat funny attempts to remedy this by introducing "shortcuts" like this: function a() { return func_get-args(); }. Of course this doesn't work when you need to specify the key name, and the overhead isn't worth it.
It looks as there may not be a specific reason not to allow the JS syntax as an alternative syntax (while keeping the current one in parallel):
$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
There shouldn't be confusion to the parser as the brackets aren't preceded by an identifier.
Was this discussed before on the list?
Regards,
Stan Vassilev
Hello
Em Qui, 2008-05-22 às 05:12 +0300, Stan Vassilev | FM escreveu:
Was this discussed before on the list?
Yes.
http://marc.info/?l=php-internals&m=119995972028293&w=2
Regards,
Stan Vassilev
--
Regards,
Felipe Pena.
Hi!
$a = [[1, 2], [3, 4], 5, 6];
Proposed twice at least, but PHP developer community doesn't seem to
like it.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
$a = [[1, 2], [3, 4], 5, 6];
Proposed twice at least, but PHP developer community doesn't seem to like
it.
Many of us like it. And the end users I know like it too.
Cheers,
Hi!
$a = [[1, 2], [3, 4], 5, 6];
Proposed twice at least, but PHP developer community doesn't seem to like
it.Many of us like it. And the end users I know like it too.
I see no advantages here, only another way to do already possible thing and
yet another way to confuse people.
But starting this discussion from the very beginning makes very little sense.
--
Wbr,
Antony Dovgal
Hi!
$a = [[1, 2], [3, 4], 5, 6];
Proposed twice at least, but PHP developer community doesn't seem to like
it.Many of us like it. And the end users I know like it too.
I see no advantages here, only another way to do already possible thing and
yet another way to confuse people.
But starting this discussion from the very beginning makes very little
sense.
Agreed, we should simply go through a vote and be done with that.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hi,
Agreed, we should simply go through a vote and be done with that.
Vote until all are annoyed and don't vote against it anymore just to
stop voting? ("it's less annoying to have it than vote about it every
two months") There was some voting about this feature quite recently,
don't have the archive link at hand.
johannes
Hi,
Agreed, we should simply go through a vote and be done with that.
Vote until all are annoyed and don't vote against it anymore just to
stop voting? ("it's less annoying to have it than vote about it every
two months") There was some voting about this feature quite recently,
don't have the archive link at hand.
Really? I missed the conclusion then. But if there was one, let begin to count.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
On Thu, May 22, 2008 at 3:56 PM, Johannes Schlüter
johannes@php.net wrote:Hi,
Agreed, we should simply go through a vote and be done with that.
Vote until all are annoyed and don't vote against it anymore just to
stop voting? ("it's less annoying to have it than vote about it every
two months") There was some voting about this feature quite recently,
don't have the archive link at hand.Really? I missed the conclusion then. But if there was one, let
begin to count.
Whether something is concluded or not is in the eye of the beholder...
but it appears the conclusion here is:
This is too much [unnecessary] magic:
Regards,
Philip
Not sure we really reached a conclusion. I think it was inconclusive and people got tired.
As I've stated in the past in general I don't like the ability to do things in more than one way but in this case I think the advantages of the cleaner syntax outweigh the fact that we'd have two ways. I'd prefer to support [] but I don't think it's a huge deal if we don't do it. It would make PHP a bit nicer :)
Andi
Andi Gutmans wrote:
Not sure we really reached a conclusion. I think it was inconclusive and people got tired.
As I've stated in the past in general I don't like the ability to do things in more than one way but in this case I think the advantages of the cleaner syntax outweigh the fact that we'd have two ways. I'd prefer to support [] but I don't think it's a huge deal if we don't do it. It would make PHP a bit nicer :)
Andi
I almost typed it the other day not thinking. Been doing a lot of YUI
and {} and [] are growing on me.
+1
--
Brian Moon
Senior Developer/Engineer
When you care enough to spend the very least.
http://dealnews.com/
Hello,
-100. This discussion is closed long ago.
Andi Gutmans wrote:
It would make PHP a bit nicer :)
Andi
I almost typed it the other day not thinking. Been doing a lot of YUI and
{} and [] are growing on me.+1
For the record here, +1.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
For the record here, +1.
+1 (for informational purposes, do not have karma to actually vote)
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Andi Gutmans schrieb:
Not sure we really reached a conclusion. I think it was inconclusive and people got tired.
As I've stated in the past in general I don't like the ability to do things in more than one way but in this case I think the advantages of the cleaner syntax outweigh the fact that we'd have two ways. I'd prefer to support [] but I don't think it's a huge deal if we don't do it. It would make PHP a bit nicer :)
Andi
can I take this one as a +1?
Sebastian
Johannes Schlüter wrote:
Hi,
Agreed, we should simply go through a vote and be done with that.
Vote until all are annoyed and don't vote against it anymore just to
stop voting? ("it's less annoying to have it than vote about it every
two months") There was some voting about this feature quite recently,
don't have the archive link at hand.
I vote for no votes. They're meaningless anyway. Whoever commits first,
wins. ;)
Pierre: Care to reply to my email (sent to pierre.dev@gmail.com several
times now..)
--Jani
+1
Johannes Schlüter wrote:
Hi,
Agreed, we should simply go through a vote and be done with that.
Vote until all are annoyed and don't vote against it anymore just to
stop voting? ("it's less annoying to have it than vote about it every
two months") There was some voting about this feature quite recently,
don't have the archive link at hand.I vote for no votes. They're meaningless anyway. Whoever commits first,
wins. ;)Pierre: Care to reply to my email (sent to pierre.dev@gmail.com several
times now..)--Jani
Hi!
Many of us like it. And the end users I know like it too.
You don't need to convince me :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I'm not using this syntax. But I don't oppose it.
Hi,
I hear this often by other developers and I tend to agree with them, that arrays are used often, and often nested, so that having a long syntax for array literals tend to produce less legible code than in other scriping languages.
$a = array(array(1,2), array(3,4), 5, 6);
$b = array('a' => 1, 'b' =>2);
We use arrays in our configurations, in passing complex parameters to functions, fetching information from databases, basically everything. So it adds up.
Some frameworks have somewhat funny attempts to remedy this by introducing "shortcuts" like this: function a() { return func_get-args(); }. Of course this doesn't work when you need to specify the key name, and the overhead isn't worth it.
It looks as there may not be a specific reason not to allow the JS syntax as an alternative syntax (while keeping the current one in parallel):
$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
There shouldn't be confusion to the parser as the brackets aren't preceded by an identifier.
Was this discussed before on the list?
Regards,
Stan Vassilev
--
Regards,
Wang Yi
dont have karma - but I would love it! so +1 here.
would it make sense to write an RFC?
cheers
Sebastian
Stan Vassilev | FM schrieb:
Hi,
I hear this often by other developers and I tend to agree with them, that arrays are used often, and often nested, so that having a long syntax for array literals tend to produce less legible code than in other scriping languages.
$a = array(array(1,2), array(3,4), 5, 6);
$b = array('a' => 1, 'b' =>2);
We use arrays in our configurations, in passing complex parameters to functions, fetching information from databases, basically everything. So it adds up.
Some frameworks have somewhat funny attempts to remedy this by introducing "shortcuts" like this: function a() { return func_get-args(); }. Of course this doesn't work when you need to specify the key name, and the overhead isn't worth it.
It looks as there may not be a specific reason not to allow the JS syntax as an alternative syntax (while keeping the current one in parallel):
$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
There shouldn't be confusion to the parser as the brackets aren't preceded by an identifier.
Was this discussed before on the list?
Regards,
Stan Vassilev
fyi - i added a RFC
http://wiki.php.net/rfc/shortsyntaxforarrays
please add your votes
cheers
Sebastian
Sebastian Deutsch schrieb:
dont have karma - but I would love it! so +1 here.
would it make sense to write an RFC?cheers
Sebastian
Stan Vassilev | FM schrieb:
Hi,
I hear this often by other developers and I tend to agree with them,
that arrays are used often, and often nested, so that having a long
syntax for array literals tend to produce less legible code than in
other scriping languages.$a = array(array(1,2), array(3,4), 5, 6);
$b = array('a' => 1, 'b' =>2);
We use arrays in our configurations, in passing complex parameters to
functions, fetching information from databases, basically everything.
So it adds up.Some frameworks have somewhat funny attempts to remedy this by
introducing "shortcuts" like this: function a() { return
func_get-args(); }. Of course this doesn't work when you need to
specify the key name, and the overhead isn't worth it.It looks as there may not be a specific reason not to allow the JS
syntax as an alternative syntax (while keeping the current one in
parallel):$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
There shouldn't be confusion to the parser as the brackets aren't
preceded by an identifier.Was this discussed before on the list?
Regards, Stan Vassilev
please add your votes
I'm +1.
BTW - how hard would it be to add voting interface to the wiki?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev kirjoitti:
please add your votes
I'm +1.
BTW - how hard would it be to add voting interface to the wiki?
For the record: I'm -1. array() is enough.
Ridiculous idea to begin with..and please no more voting, isn't there enough
spam already?
--Jani
Hi!
Ridiculous idea to begin with..and please no more voting, isn't there
enough spam already?
What do you mean "no more voting"?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev kirjoitti:
please add your votes
I'm +1.
BTW - how hard would it be to add voting interface to the wiki?
For the record: I'm -1. array() is enough.
Ridiculous idea to begin with..and please no more voting, isn't there enough
spam already?
I agree on both points. I've mentioned this before as well, but I'll
repeat. There is no reason to add another syntax for exactly the same
thing, especially because it's ungoogable and confusing if you have to
read code like:
$a = [8,['a','b','c'],'foo'];
$b = $a[8][1];
Please let's not turn PHP into unreadable syntax like perl usually
advocates. Besides this, it's only really useful for multi-dimensional
arrays - and if you go there you've most likely lost anyway.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Tuesday, May 27, 2008 11:32 PM
To: jani.taskinen@iki.fi
Cc: Sebastian Deutsch; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Re: Short syntax for array literals [...]Please let's not turn PHP into unreadable syntax like perl usually
advocates. Besides this, it's only really useful for multi-dimensional
arrays - and if you go there you've most likely lost anyway.
I personally would also prefer this syntax over array() for single dimensional arrays.
Andi
+1 for: ['foo' => 'bar'], Not sure if it was decided but -1 for ['foo':
'bar']
Here is why,
Array(), is much more confusing to someone coming with no experience in php
then []. Array() in most languages looks like a function call. So
Array('foo' => 'bar'), verse ['foo' => 'bar'], most people will more easily
understand the latter when entering into the language fresh.
I.E.:
$f = Array('foo' => 'bar');
$f('foo'); // comes to mind first right, might not for a php developer but
for a new comer maybe?
$f = ['foo' => 'bar'];
$f['foo']; // great
Gives our users options, and does not break any existing code or enforce new
programming paradigm. The change is minor and no real cost in performance.
As for existing users, I find the completely negative comments a real
hindrance on the evolution of php as a language. If something does not
damage the language but will offer benefits for a broad user base, as well
as existing code, then let it be. I for one will change every line of code I
have that uses the Array() syntax for the shorter, more WIDELY readable []
syntax.
My only curiosity is if this will turn into a ecmascript morphism and we
wind up with a new object proposal instead of stdclass, like
$oStd = {'foo' => 'bar'};
echo $oStd->foo;
... doesn't even look all that bad but feels wrong and dirty, I think I
would rather (object) ['foo' => 'bar']; :p
-Chris
In my opinion I don't think PHP would be where it is today if it wasn't
for being so easy to learn and use.
I attribute this directly to the fact that it didn't use a lot of
"syntax sugar" that is unreadable and can't be "Googled" for. You can't
Google "[]", and my guess is searching PHP.net for "[]" won't return
anything useful either.
Using Array() is SELF EXPLANATORY! Anyone can see that, search Google
for "Array" and learn something about it.
How many man hours are going to be wasted:
- Searching for what the heck [] actually is.
- Explaining to people that [] is the same as Array.
- Changing coding standards for projects to prevent [] from being
used. - Enforcing coding standards for projects to prevent [] from being
used. - Trying to change [] back to Array in hopes of getting code to work on
older versions of PHP. - All the man hours wasted on it ALREADY that I'm sure could be much
better spent getting PHP 5.3/6.0 out.
There are enough roadblocks and other things to worry about already, why
would we want to add MORE? Especially for something with so little to
gain (if anything at all).
This isn't about "well if you don't like it, don't use it" either,
because no matter what it will be forced on people who don't like it
eventually. People who like it will be constantly changing Array() -> []
and people who hate it will be constantly changing [] -> Array(). More
wasted time.
Just my two cents.
+1 for: ['foo' => 'bar'], Not sure if it was decided but -1 for ['foo':
'bar']Here is why,
Array(), is much more confusing to someone coming with no experience in php
then []. Array() in most languages looks like a function call. So
Array('foo' => 'bar'), verse ['foo' => 'bar'], most people will more easily
understand the latter when entering into the language fresh.I.E.:
$f = Array('foo' => 'bar');
$f('foo'); // comes to mind first right, might not for a php developer but
for a new comer maybe?$f = ['foo' => 'bar'];
$f['foo']; // greatGives our users options, and does not break any existing code or enforce new
programming paradigm. The change is minor and no real cost in performance.As for existing users, I find the completely negative comments a real
hindrance on the evolution of php as a language. If something does not
damage the language but will offer benefits for a broad user base, as well
as existing code, then let it be. I for one will change every line of code I
have that uses the Array() syntax for the shorter, more WIDELY readable []
syntax.My only curiosity is if this will turn into a ecmascript morphism and we
wind up with a new object proposal instead of stdclass, like$oStd = {'foo' => 'bar'};
echo $oStd->foo;... doesn't even look all that bad but feels wrong and dirty, I think I
would rather (object) ['foo' => 'bar']; :p-Chris
--
Mike <ipso@snappymail.ca
Exactly. Open this can of worms and soon PHP is something else than easy
to learn.. someone already mentioned that {} thing for objects.. :)
Sidenote: There are more important things to solve in PHP 5.3 (and
especially HEAD) than adding this little syntax sugar..
--Jani
Mike wrote:
In my opinion I don't think PHP would be where it is today if it wasn't
for being so easy to learn and use.I attribute this directly to the fact that it didn't use a lot of
"syntax sugar" that is unreadable and can't be "Googled" for. You can't
Google "[]", and my guess is searching PHP.net for "[]" won't return
anything useful either.Using Array() is SELF EXPLANATORY! Anyone can see that, search Google
for "Array" and learn something about it.How many man hours are going to be wasted:
- Searching for what the heck [] actually is.
- Explaining to people that [] is the same as Array.
- Changing coding standards for projects to prevent [] from being
used.- Enforcing coding standards for projects to prevent [] from being
used.- Trying to change [] back to Array in hopes of getting code to work on
older versions of PHP.- All the man hours wasted on it ALREADY that I'm sure could be much
better spent getting PHP 5.3/6.0 out.There are enough roadblocks and other things to worry about already, why
would we want to add MORE? Especially for something with so little to
gain (if anything at all).This isn't about "well if you don't like it, don't use it" either,
because no matter what it will be forced on people who don't like it
eventually. People who like it will be constantly changing Array() -> []
and people who hate it will be constantly changing [] -> Array(). More
wasted time.Just my two cents.
+1 for: ['foo' => 'bar'], Not sure if it was decided but -1 for ['foo':
'bar']Here is why,
Array(), is much more confusing to someone coming with no experience in php
then []. Array() in most languages looks like a function call. So
Array('foo' => 'bar'), verse ['foo' => 'bar'], most people will more easily
understand the latter when entering into the language fresh.I.E.:
$f = Array('foo' => 'bar');
$f('foo'); // comes to mind first right, might not for a php developer but
for a new comer maybe?$f = ['foo' => 'bar'];
$f['foo']; // greatGives our users options, and does not break any existing code or enforce new
programming paradigm. The change is minor and no real cost in performance.As for existing users, I find the completely negative comments a real
hindrance on the evolution of php as a language. If something does not
damage the language but will offer benefits for a broad user base, as well
as existing code, then let it be. I for one will change every line of code I
have that uses the Array() syntax for the shorter, more WIDELY readable []
syntax.My only curiosity is if this will turn into a ecmascript morphism and we
wind up with a new object proposal instead of stdclass, like$oStd = {'foo' => 'bar'};
echo $oStd->foo;... doesn't even look all that bad but feels wrong and dirty, I think I
would rather (object) ['foo' => 'bar']; :p-Chris
Hello,
On Wed, May 28, 2008 at 10:25 AM, Jani Taskinen jani.taskinen@sci.fi
wrote:
Exactly. Open this can of worms and soon PHP is something else than easy to
learn.. someone already mentioned that {} thing for objects.. :)Sidenote: There are more important things to solve in PHP 5.3 (and
especially HEAD) than adding this little syntax sugar..--Jani
It's not syntax sugar, it's a construct which is used across many other
languages. It will improve the language for other people and might help
people to learn PHP. If we have resource issues commiting one line of
grammar the project has other issues to deal with.
Mike wrote:
In my opinion I don't think PHP would be where it is today if it wasn't
for being so easy to learn and use.I attribute this directly to the fact that it didn't use a lot of
"syntax sugar" that is unreadable and can't be "Googled" for. You can't
Google "[]", and my guess is searching PHP.net for "[]" won't return
anything useful either.
Using Array() is SELF EXPLANATORY! Anyone can see that, search Google
for "Array" and learn something about it.
How many man hours are going to be wasted:
- Searching for what the heck [] actually is.
Anyone who has gotten to a level of knowing how to assign php variables will
likely have any troubles understanding what:
$config = ['smtpHost' => 'example.org'];
$oSmtp = someSmtpTransport($config['smtpHost']);
Is doing, and if you have a super complex multi-dimensional array,
regardless of brackets or array syntax it will be hard to understand by a
php new comer.
- Explaining to people that [] is the same as Array.
$foo = Array('foo' => 'bar');
var_dump($foo);
$foo = ['foo' => 'bar'];
var_dump($foo);
Explained.
- Changing coding standards for projects to prevent [] from being
used.
- Enforcing coding standards for projects to prevent [] from being
used.
$str = "$var {$foo} " . $bar . " $see " . ' tconst ' . $not . ' $parsed ';
We already face issues with more then one way to do things, we deal with it
and it has not proven to be to difficult.
- Trying to change [] back to Array in hopes of getting code to work on
older versions of PHP.If your projects target versions are older versions then create backwards
compatible code just like you do with PHP4 classes and PHP5 classes.
- All the man hours wasted on it ALREADY that I'm sure could be much
better spent getting PHP 5.3/6.0 out.The discussion is the wasted time, not the code or implementation.
There are enough roadblocks and other things to worry about already, why
would we want to add MORE? Especially for something with so little to
gain (if anything at all).Gain to whom? Remember, their is an entire community of developers out
their besides the people on this list who are accustomed to such use for
arrays. Also, a community of developers who would like an alternative syntax
to array to clean up their code a little, like me.
This isn't about "well if you don't like it, don't use it" either,
because no matter what it will be forced on people who don't like it
eventually. People who like it will be constantly changing Array() -> []
and people who hate it will be constantly changing [] -> Array(). More
wasted time.Just like string literals $str = 'foo'; and $str = "foo";
class Foo {
public $bar;
public $baz;
public $qux;
VS
class Foo {
public $bar, $baz, $qux;
$obj = new Stdclass;
$obj = (object) NULL;
Really guys my only point is that we should not disregard a proposal for the
sake of having more then one way to do something. That is the beauty of PHP
and any successful language, it appeals to a wide variety of coding
standards, methodologies and paradigms. If you just think about it you can
name tons of things in PHP that let you do the same thing with two syntax's.
This is part of php's success. Some things are easier for people to learn
then they are for others.
-Chris
Mike wrote:
In my opinion I don't think PHP would be where it is today if it wasn't
for being so easy to learn and use.I attribute this directly to the fact that it didn't use a lot of
"syntax sugar" that is unreadable and can't be "Googled" for. You can't
Google "[]", and my guess is searching PHP.net for "[]" won't return
anything useful either.
Can you google for this:
$var = 1;
$var = "foo";
?
--
Brian Moon
Senior Developer/Engineer
When you care enough to spend the very least.
http://dealnews.com/
Mike wrote:
In my opinion I don't think PHP would be where it is today if it wasn't
for being so easy to learn and use.I attribute this directly to the fact that it didn't use a lot of
"syntax sugar" that is unreadable and can't be "Googled" for. You can't
Google "[]", and my guess is searching PHP.net for "[]" won't return
anything useful either.Using Array() is SELF EXPLANATORY! Anyone can see that, search Google
for "Array" and learn something about it.How many man hours are going to be wasted:
- Searching for what the heck [] actually is.
This "No Magic" mantra is something I have been using since day one to
guide decisions like this in PHP. But I think you guys are
misappropriating it. [] is already our array syntax. $a[1] assumes
that the user realize that [] has something to do with arrays. If they
don't, they are out of luck, because as you say, you can't search for []
and get something useful. But that's already the case and we are simply
building on that existing knowledge. We have to have a minimum set of
operators that we feel reasonable certain that people understand. ?: is
also not easy to search for, yet we added this ternary shortcut.
Likewise, <<< is not easy to look up, but we added HEREDOC and more
recently NOWDOC with this syntax.
PHP is about building on the knowledge and experience of the typical
target user. This target user changes slowly as we all get older and
the industry we are in changes and we need to recognize that and adapt
the language appropriately. What is appropriate is of course a really
hard call which is what this is all about.
-Rasmus
Mike wrote:
In my opinion I don't think PHP would be where it is today if it wasn't
for being so easy to learn and use.I attribute this directly to the fact that it didn't use a lot of
"syntax sugar" that is unreadable and can't be "Googled" for. You
can't Google "[]", and my guess is searching PHP.net for "[]" won't
return anything useful either. Using Array() is SELF EXPLANATORY!
Anyone can see that, search Google for "Array" and learn something
about it. How many man hours are going to be wasted: 1. Searching
for what the heck [] actually is.This "No Magic" mantra is something I have been using since day one to guide
decisions like this in PHP. But I think you guys are misappropriating it. []
is already our array syntax.
Yes, as an indexing mechanism for strings and arrays - that is
different from a construct of actually defining it. They are two
different things.
$a[1] assumes that the user realize that [] has something to do with
arrays. If they don't, they are out of luck, because as you say, you
can't search for [] and get something useful. But that's already the
case and we are simply building on that existing knowledge. We have
to have a minimum set of operators that we feel reasonable certain
that people understand. ?: is also not easy to search for, yet we
added this ternary shortcut. Likewise, <<< is not easy to look up, but
we added HEREDOC and more recently NOWDOC with this syntax.
There is one difference though. The NOWDOC construct allows actually
something new, whereas [ ] would just be an alternative for
something can already do.
PHP is about building on the knowledge and experience of the typical
target user. This target user changes slowly as we all get older and
the industry we are in changes and we need to recognize that and adapt
the language appropriately. What is appropriate is of course a really
hard call which is what this is all about.
I'd have less issues with adding [] as the array() syntax if it was
something that PHP didn't support yet. But we're 12 years down the road
now and since arrays were introduced we've always used array(). I
realize that there are now other languages that favor this construct,
but I don't see why we should then add it as the exact same thing as
an already existing construct.
I'd be greatly disapointed if a construct would make it into PHP. I
think it's the wrong way to go by adding cryptic constructs for
something that we've already syntax for. Really, adding 5 more chars
doesn't make any difference, and using the full "array()" increases
readability as it's an explicit statement. Besides the mantra that you
mention, there is another one that we shouldn't keep out of the picture
either: PHP is suppose to be easy to pick up, and use, and so far we've
done that by requiring explicit names for constructs (with the few
exceptions of course). This is why we use array(), $ in front of vars,
and preg_match over =~.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
hi Derick,
I'd have less issues with adding [] as the array() syntax if it was
something that PHP didn't support yet. But we're 12 years down the road
now and since arrays were introduced we've always used array().
I'd have less issues with our OO strictness and the numerous new fatal
errors for non engine critical problems. But know what? no one is
arguing about that anymore even if today's php is stricter than
php/fi. (put some salt on this answer, it is meant to show how wrong
is this argument).
Cheers,
You don't really have any vote anyway, you lost that when you tricked me for
doing your work for you and took the money and run away..
--Jani
Pierre Joye kirjoitti:
hi Derick,
I'd have less issues with adding [] as the array() syntax if it was
something that PHP didn't support yet. But we're 12 years down the road
now and since arrays were introduced we've always used array().I'd have less issues with our OO strictness and the numerous new fatal
errors for non engine critical problems. But know what? no one is
arguing about that anymore even if today's php is stricter than
php/fi. (put some salt on this answer, it is meant to show how wrong
is this argument).Cheers,
It's a big +1 for me and this sums it up
PHP is about building on the knowledge and experience of the typical
target user. This target user changes slowly as we all get older and
the industry we are in changes and we need to recognize that and adapt
the language appropriately. What is appropriate is of course a really
hard call which is what this is all about.
My first concern about the [] debate is no one is really asking what the
users want? Where did the [] requirement or proposal come from? There's no
doubt in my mind that a [] synthax is something most users would want. The
similar array declaration to javascript also further reinforces the use of
PHP for web based programming.
Finally, having a public voting system would definitely help gain more
insight as to what users want.
I think a public voting system is not a good thing (though the idea
appealed me in the first place) - but I was convinced that it would lead
to vote without discussion.
For "listening to the user base" I originally had a headline "Discussion
on the Web" were I refered to some blog posts covering that topic.
Actually someone removed it by "Discussion on the List".
Jonathan Bond-Caron schrieb:
It's a big +1 for me and this sums it up
PHP is about building on the knowledge and experience of the typical
target user. This target user changes slowly as we all get older and
the industry we are in changes and we need to recognize that and adapt
the language appropriately. What is appropriate is of course a really
hard call which is what this is all about.My first concern about the [] debate is no one is really asking what the
users want? Where did the [] requirement or proposal come from? There's no
doubt in my mind that a [] synthax is something most users would want. The
similar array declaration to javascript also further reinforces the use of
PHP for web based programming.Finally, having a public voting system would definitely help gain more
insight as to what users want.
Stanislav Malyshev wrote:
please add your votes
I'm +1.
I'm ok with it as well. Like I said over a year ago (*), it is a syntax
very familiar to web developers and it feels natural to most people.
(*) http://marc.info/?l=php-internals&m=117060700805108&w=2
-Rasmus
Stanislav Malyshev wrote:
please add your votes
I'm +1.
Same here, still +1.
Cheers,
Stanislav Malyshev schrieb:
please add your votes
I'm +1.
BTW - how hard would it be to add voting interface to the wiki?
I don't think it's hard:
http://wiki.splitbrain.org/plugin:poll
http://wiki.splitbrain.org/plugin:userpoll
Sebastian
Stanislav Malyshev wrote:
please add your votes
I'm +1.
BTW - how hard would it be to add voting interface to the wiki?
Not hard at all. Certifying that people only vote once - hard
:)
Greg
Stanislav Malyshev wrote:
please add your votes
I'm +1.
BTW - how hard would it be to add voting interface to the wiki?Not hard at all. Certifying that people only vote once - hard
I vote we don't talk about voting methodology in this thread.
Regards,
Philip
Hi!
Not hard at all. Certifying that people only vote once - hard
What's hard in that? Only logged in users vote, one login - one vote. :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
Not hard at all. Certifying that people only vote once - hard
What's hard in that? Only logged in users vote, one login - one vote. :)
Verifying that one user hasn't created hundreds of accounts for voting
purposes? No problem if voting is linked to a php.net account, of course.
Greg
Hi!
Verifying that one user hasn't created hundreds of accounts for voting
purposes? No problem if voting is linked to a php.net account, of course.
I'd say linking voting to having php.net account would make sense. For
general "anybody can vote" vote one always can create a poll on any free
poll site ;)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I'm +1.
-Andrei
Sebastian Deutsch wrote:
fyi - i added a RFC
http://wiki.php.net/rfc/shortsyntaxforarrays
please add your votes
cheers
Sebastian
fyi - i added a RFC
http://wiki.php.net/rfc/shortsyntaxforarrays
please add your votes
You do understand that you will not be able to use this syntax in your products
for at least next 5 years without rising min required PHP version to the latest one, right?
That makes it even more useless.
--
Wbr,
Antony Dovgal
Hi!
You do understand that you will not be able to use this syntax in your
products for at least next 5 years without rising min required PHP
version to the latest one, right?
That makes it even more useless.
That's great argument. So nice to know everything we do for 5.3 and 6 is
completely useless :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
You do understand that you will not be able to use this syntax in your
products for at least next 5 years without rising min required PHP
version to the latest one, right?
That makes it even more useless.That's great argument. So nice to know everything we do for 5.3 and 6 is
completely useless :)
No, THAT is really great argument.
Compare "everything we do" with "backward incompatible syntax that duplicates
already existing one, but 5 characters shorter" and find two differences.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Hi!
You do understand that you will not be able to use this syntax in
your products for at least next 5 years without rising min required
PHP version to the latest one, right?
That makes it even more useless.That's great argument. So nice to know everything we do for 5.3 and 6
is completely useless :)No, THAT is really great argument.
Compare "everything we do" with "backward incompatible syntax that
duplicates already existing one, but 5 characters shorter" and find two
differences.
At a certain level everything is just syntax. There is nothing about a
"for" loop that can't be done with a "while" loop. All OO code could be
written procedurally as well. PHP has always made an effort to match
the expectations of the typical web developer. 14 years ago the typical
web developer knew Perl and C, so a lot of syntax was borrowed from
those two languages.
Then kids started coming out of universities with Java on their brains,
so PHP adopted a Java-like OO syntax. Today's web developer is
typically writing half their app in some variety of Ecmascript, either
Javascript or Actionscript and this array syntax is second nature to all
those folks.
We have to be very conservative and pick our spots when it comes to
evolving the language syntax, but we also can't bunker down and get
stubborn and expect the world to stand still around us. If we had taken
that same position at PHP 2, PHP 3, PHP 4 or even PHP 5 just because a
handful of developers were content with the current state of things, we
would be in serious trouble today.
-Rasmus
On 28.05.2008 10:44, Rasmus Lerdorf wrote:
Today's web developer is
typically writing half their app in some variety of Ecmascript, either
Javascript or Actionscript and this array syntax is second nature to all
those folks.
I don't recall any languages to introduce new syntax because it's so handy
to those who come from PHP and I see no reasons for us to do it either.
I perfectly understand that we (well, you) did it many times in the beginning,
but I believe that time is now gone.
The array syntax we have exists for many years and is used in gazillions lines of code,
it's known to every developer who have ever seen a PHP script.
In the same time, the [] syntax will definitely confuse people (wth? this surely
looks like invalid syntax!) and will only help to those how don't know PHP, but
have a certain experience with *script languages, i.e. you're going to do a favor
for 1% and confuse the remaining 99%.
And at last, but not least I don't see anything "more readable and maintainable" in using
square brackets to initialize arrays when the same brackets are used to access them:
$a = [$a[1][2], 3]; /* wth does this mean? */
--
Wbr,
Antony Dovgal
On 28.05.2008 10:44, Rasmus Lerdorf wrote:
Today's web developer is typically writing half their app in some
variety of Ecmascript, either Javascript or Actionscript and this
array syntax is second nature to all those folks.I don't recall any languages to introduce new syntax because it's so
handy to those who come from PHP and I see no reasons for us to do it
either. I perfectly understand that we (well, you) did it many times
in the beginning, but I believe that time is now gone.The array syntax we have exists for many years and is used in
gazillions lines of code, it's known to every developer who have ever
seen a PHP script. In the same time, the [] syntax will definitely
confuse people (wth? this surely looks like invalid syntax!) and will
only help to those how don't know PHP, but have a certain experience
with *script languages, i.e. you're going to do a favor for 1% and
confuse the remaining 99%.
Right, and I will add immediately to my coding standard that this is
forbidden to use.
regards,
Derick
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Right, and I will add immediately to my coding standard that this is
forbidden to use.
... which doesn't help people having to read code without being able to
influence the coding style...
johannes
Today's web developer is typically writing half their app in some variety
of Ecmascript, either Javascript or Actionscript and this array syntax is
second nature to all those folks.I don't recall any languages to introduce new syntax because it's so handy
to those who come from PHP and I see no reasons for us to do it either.
I perfectly understand that we (well, you) did it many times in the
beginning, but I believe that time is now gone.The array syntax we have exists for many years and is used in gazillions
lines of code,
it's known to every developer who have ever seen a PHP script.
In the same time, the [] syntax will definitely confuse people (wth? this
surely looks like invalid syntax!) and will only help to those how don't
know PHP, but have a certain experience with *script languages, i.e. you're
going to do a favor for 1% and confuse the remaining 99%.
percentage is way different. such "short array syntax" is a common
ground for a lot of modern dynamic languages. and common ground is
nice (it makes life easier not only to people who come to php from
other languages, but also to people who would come to other languages,
like javascript, after php)
And at last, but not least I don't see anything "more readable and
maintainable" in using square brackets to initialize arrays when the same
brackets are used to access them:$a = [$a[1][2], 3]; /* wth does this mean? */
initialize variable $a as array, with elements:
- value-of-key "2" of array located at key "1" of old array $a
- 3
difficult to "spell", but easy to understand
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
know PHP, but have a certain experience with *script languages, i.e. you're
going to do a favor for 1% and confuse the remaining 99%.percentage is way different. such "short array syntax" is a common
ground for a lot of modern dynamic languages.
People who do not know PHP and come from *script languages are surely
NOT the majority and I daresay their number is infinitely smaller than the
number of people who know array() syntax by heart.
And at last, but not least I don't see anything "more readable and
maintainable" in using square brackets to initialize arrays when the same
brackets are used to access them:$a = [$a[1][2], 3]; /* wth does this mean? */
initialize variable $a as array, with elements:
- value-of-key "2" of array located at key "1" of old array $a
- 3
difficult to "spell", but easy to understand
Will you spell it for me each time I stumble upon such a "readable" construct, pretty please?
--
Wbr,
Antony Dovgal
Hi!
I don't recall any languages to introduce new syntax because it's so
handy to those who come from PHP and I see no reasons for us to do it
either.
If they don't do it and we do, people come from them to us and not the
reverse. The reason is to make life easier for people. And I think
current results - 21:8 - tell something.
In the same time, the [] syntax will definitely confuse people (wth?
$a = [$a[1][2], 3]; /* wth does this mean? */
I do not and will not believe that you - or anybody smart enough to use
PHP - would seriously have any trouble understanding what that means.
Arguing it is extraneous is one thing, but presenting PHP users as
senseless robots hopelessly confused by even simplest concepts like
using [] for arrays just doesn't make any sense.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
I don't recall any languages to introduce new syntax because it's so
handy to those who come from PHP and I see no reasons for us to do it
either.If they don't do it and we do, people come from them to us and not the
reverse.
Yeah, from Javascript to PHP just because of better syntax. HA.
The reason is to make life easier for people. And I think
current results - 21:8 - tell something.
Want me to find some more 50 people to vote against it?
We're having a conference these days, I believe I can find even more people
just to show you how meaningless these votes are =)
I do not and will not believe that you - or anybody smart enough to use
PHP - would seriously have any trouble understanding what that means.
Arguing it is extraneous is one thing, but presenting PHP users as
senseless robots hopelessly confused by even simplest concepts like
using [] for arrays just doesn't make any sense.
Wasn't that the main reason FOR adding this syntax?
The array() thing seems to you too hard to read and maintain, no?
If it's not, than I don't see what you're arguing for.
--
Wbr,
Antony Dovgal
Hi!
Want me to find some more 50 people to vote against it?
If you find 50 active commiters against it - I think it'd make sense to
hear what they have to say. Ask them why they didn't say anything by now.
We're having a conference these days, I believe I can find even more
people just to show you how meaningless these votes are =)
OK, they are meaningless. What is meaningful?
Wasn't that the main reason FOR adding this syntax?
The array() thing seems to you too hard to read and maintain, no?
Yes. In many cases new one is better than the old one. In some cases, it
might not be - but nobody proposes to remove array(). One can find a way
to mangle almost any syntax - that's not the point. The point is that it
is useful in a lot of cases.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
Want me to find some more 50 people to vote against it?
If you find 50 active commiters against it
Ah, you mean active commiters..
Then you probably will want to know that the actual number is 6:5
if you count only active contributors and not 21:8.
Where did you manage to find 21 active commiter btw?
We're having a conference these days, I believe I can find even more
people just to show you how meaningless these votes are =)OK, they are meaningless. What is meaningful?
The reason?
Wasn't that the main reason FOR adding this syntax?
The array() thing seems to you too hard to read and maintain, no?Yes. In many cases new one is better than the old one. In some cases, it
might not be - but nobody proposes to remove array(). One can find a way
to mangle almost any syntax - that's not the point. The point is that it
is useful in a lot of cases.
Nice.
So you can present PHP users as senseless robots that are unable to understand
array() syntax and I can't point to the extreme UNreadability of [] because ..
because .. you do not agree?
The next step would be to call me a blasphemer and pronounce anathema upon me
because I refuse to vote for a feature that have already been voted against.
But why not? Go on, vote forever until it's in.
--
Wbr,
Antony Dovgal
Hi!
So you can present PHP users as senseless robots that are unable to
understand array() syntax and I can't point to the extreme UNreadability
Nobody ever did that.
The next step would be to call me a blasphemer and pronounce anathema
upon me because I refuse to vote for a feature that have already been
voted against.
You didn't refuse to vote. You voted against. You vote was counted.
What's you problem now? You losing a vote?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
-1
regards,
Lukas
On Wednesday 28 May 2008 09:11:50 Antony Dovgal wrote:
Today's web developer is
typically writing half their app in some variety of Ecmascript, either
Javascript or Actionscript and this array syntax is second nature to all
those folks.I don't recall any languages to introduce new syntax because it's so handy
to those who come from PHP and I see no reasons for us to do it either.
I perfectly understand that we (well, you) did it many times in the
beginning, but I believe that time is now gone.
That is, maybe, because PHP didn't introduce any "new handy syntax" that could
be borrowed from other languages.
The array syntax we have exists for many years and is used in gazillions
lines of code, it's known to every developer who have ever seen a PHP
script.
And cursed many times because it's so tedious to write ...
In the same time, the [] syntax will definitely confuse people (wth? this
surely looks like invalid syntax!) and will only help to those how don't
know PHP, but have a certain experience with *script languages, i.e. you're
going to do a favor for 1% and confuse the remaining 99%.
If you look at the other mails, you'll see that it's not about helping people
that don't know PHP but other languages, but helping people writing code that
is more concise and readable ...
[[1,2,3],
[4,5,6],
[7,8,9]] is far easier to read than the same thing with array().
And at last, but not least I don't see anything "more readable and
maintainable" in using square brackets to initialize arrays when the same
brackets are used to access them:$a = [$a[1][2], 3]; /* wth does this mean? */
This "it's unreadable and confusing"-argument is odd. In years of helping
people in ruby/python*-channels, I have seen many questions, many questions
that would seem exceedingly dumb, but i can't recall a single time someone
asking about []-literals for arrays/lists, even [] is the subscript operator
too for these languages. So you'd imply that seasoned PHP developers are less
quick to understand than people that are new to other languages ... Btw, do
you complain because () is used a) to group expressions b) to call functions
c) for language constructs like for ()? Any "wth"-moments there? Or do you
wish that strings would be written as string(foo) instead of "foo"?
- Even a language that has the guideline "explicit is better than implicit"
preferred [] because it's clear and concise ... doesn't that make you wonder?
--
Wbr,
Antony Dovgal
Regards,
Stefan
Hello,
As I always will say -1 to this.
But I have a question, people here talk that this is very very useful in
some cases. Can you please show others such cases so we can get your point?
I really want to know this super hyper cases, this syntax is mega useful.
Regards, Dimitar
Hi,
No one said it's a matter of life and death. But is it only a matter of life
and death improvements that should be considered for PHP?
The typical use case that benefits most from this is when a function accepts
arrays as a means of structured/named/nested options, something I use a lot.
Compare verbosity and readability:
quoteInto('SELECT * FROM Table WHERE x > ? and y < ?', array(10, 50));
vs:
quoteInto('SELECT * FROM Table WHERE x > ? and y < ?', [10, 50]);
renderSomething(array('exclude' => array('a', 'b', 'c'), 'include' =>
array('d', 'e', 'f')));
vs:
renderSomething(['exclude' => ['a', 'b', 'c'], 'include' => ['d', 'e',
'f']]);
or even vs:
renderSomething(['exclude' : ['a', 'b', 'c'], 'include' : ['d', 'e', 'f']]);
The key thing is, no one is requesting that array() be removed. Just that an
obvious and commonly used shortcut is added. It's not confusing, it's not
hard, JavaScript also has BOTH short and long syntax for arrays and objects:
var array = new Array(); -- same as -- var array = [];
var object = new Object(); -- same as -- var object = {};
And when people have both of those, guess which one they use in more than
90% of the cases.
Regards,
Stan Vassilev
Hello,
As I always will say -1 to this.
But I have a question, people here talk that this is very very useful in
some cases. Can you please show others such cases so we can get your
point?
I really want to know this super hyper cases, this syntax is mega useful.Regards, Dimitar
2008/5/28 Stan Vassilev | FM sv_forums@fmethod.com:
var array = new Array(); -- same as -- var array = [];
var object = new Object(); -- same as -- var object = {};And when people have both of those, guess which one they use in more than
90% of the cases.Regards,
Stan Vassilev
I've moved from PHP to JS and I found this confusing. I don't any
more, but I was used to saying I wanted an array by using the Array
keyword (makes sense - no shortcut - no confusion).
I still say Array() and Object() as they explicitly declare my
intentions and others that would find [] and {} confusing (at least
initially) don't have to struggle with my code.
[] is fine for accessing an array. That's very common in many languages.
{} was confusing as that is that is used to wrap a function's code.
I don't see any real benefit in using $a = [] over $a = array()
So, for a userland developer (rather than a core developer) -1.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
The next step would be to call me a blasphemer and pronounce anathema upon
me because I refuse to vote for a feature that have already been voted
against.
But why not? Go on, vote forever until it's in.
From the looks of things, animosity also exhibits elasticity; cause, that's
one hell of a stretch.
(You want to reel it back in a bit?)
I do find it funny the type of argument this has become (it'd be even better
if the demography actually matched):
- the kids want to do something new cause - well - everyone else is doing it
- but, the parents have their house rules and traditions and are steadfast
against breaking them.
In that regard, I'd be a kid.
But I have a question, people here talk that this is very very useful in
some cases. Can you please show others such cases so we can get your point?
I really want to know this super hyper cases, this syntax is mega useful.
You can't see the enormous difference between array(5, 3) and [5, 3]?! ;)
Ok, so "easier" probably wasn't the best word to use.
"Shorter" works; but, it isn't as enticing.
The only ease I can see in it is simply for familiarity (see "kids argument"
above).
Though, the amount of ease will obviously vary from one person to another.
- Jon L.
Hello again,
renderSomething(array('exclude' => array('a', 'b', 'c'), 'include' =>
array('d', 'e', 'f')));
vs:
renderSomething(['exclude' => ['a', 'b', 'c'], 'include' => ['d', 'e',
'f']]);
Your version is more readable but try this one:
renderSomething(
array(
'exclude' => array('a', 'b', 'c'),
'include' => array('d', 'e', 'f')
)
);
Or even break array('a','b','c') and array('d', 'e', 'f') in more lines.
This will become far more readable, with proper names and values.
This is the real life case for me.
Regards, Dimitar
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, May 27, 2008 11:44 PM
To: Antony Dovgal
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Short syntax for array literals [...]At a certain level everything is just syntax. There is nothing about
a
"for" loop that can't be done with a "while" loop. All OO code could
be
written procedurally as well. PHP has always made an effort to match
the expectations of the typical web developer. 14 years ago the
typical
web developer knew Perl and C, so a lot of syntax was borrowed from
those two languages.Then kids started coming out of universities with Java on their
brains,
so PHP adopted a Java-like OO syntax. Today's web developer is
typically writing half their app in some variety of Ecmascript, either
Javascript or Actionscript and this array syntax is second nature to
all
those folks.We have to be very conservative and pick our spots when it comes to
evolving the language syntax, but we also can't bunker down and get
stubborn and expect the world to stand still around us. If we had
taken
that same position at PHP 2, PHP 3, PHP 4 or even PHP 5 just because a
handful of developers were content with the current state of things,
we
would be in serious trouble today.
I agree completely and this is exactly the situation where in the past
we did evolve the language. We've been rightfully so conservative about
it but I think this case is really a no brainer.
There's a minority here who thinks it's confusing but besides it being a
small minority, as Rasmus says, a large part of our user base especially
the new ones entering development will be very used to this syntax and
it will make their lives easier.
+1 from me (in case my previous email without the vote wasn't clear :)
Andi
Antony Dovgal wrote:
fyi - i added a RFC
http://wiki.php.net/rfc/shortsyntaxforarrays
please add your votes
You do understand that you will not be able to use this syntax in your
products for at least next 5 years without rising min required PHP
version to the latest one, right?
That makes it even more useless.
Right, so the sooner the better. =)
--
Brian Moon
Senior Developer/Engineer
When you care enough to spend the very least.
http://dealnews.com/
fyi - i added a RFC
http://wiki.php.net/rfc/shortsyntaxforarrays
please add your votes
cheers
Sebastian
I'm +1.
- Hans Å
-1.
(the syntax with colons is appalling, and the other one doesn't look
any more readable - and is not javascript-ish either, since JS arrays
can only have numeric keys. I'd welcome the syntax without any chance
of specifying keys, but then, that'd be a really half-arsed solution)
Am 28.05.2008 um 00:58 schrieb Sebastian Deutsch:
fyi - i added a RFC
http://wiki.php.net/rfc/shortsyntaxforarrays
please add your votes
cheers
Sebastian
Sebastian Deutsch schrieb:
dont have karma - but I would love it! so +1 here.
would it make sense to write an RFC?
cheers
Sebastian
Stan Vassilev | FM schrieb:Hi,
I hear this often by other developers and I tend to agree with
them, that arrays are used often, and often nested, so that having
a long syntax for array literals tend to produce less legible code
than in other scriping languages.$a = array(array(1,2), array(3,4), 5, 6);
$b = array('a' => 1, 'b' =>2);
We use arrays in our configurations, in passing complex parameters
to functions, fetching information from databases, basically
everything. So it adds up.Some frameworks have somewhat funny attempts to remedy this by
introducing "shortcuts" like this: function a() { return
func_get-args(); }. Of course this doesn't work when you need to
specify the key name, and the overhead isn't worth it.It looks as there may not be a specific reason not to allow the JS
syntax as an alternative syntax (while keeping the current one in
parallel):$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
There shouldn't be confusion to the parser as the brackets aren't
preceded by an identifier.Was this discussed before on the list?
Regards, Stan Vassilev
2008/5/27, Sebastian Deutsch sebastian.deutsch@9elements.com:
fyi - i added a RFC
http://wiki.php.net/rfc/shortsyntaxforarrays
please add your votes
I'm -1.
cheers
Sebastian
Sebastian Deutsch schrieb:
dont have karma - but I would love it! so +1 here.
would it make sense to write an RFC?cheers
Sebastian
Stan Vassilev | FM schrieb:
Hi,
I hear this often by other developers and I tend to agree with them,
that arrays are used often, and often nested, so that having a long syntax
for array literals tend to produce less legible code than in other scriping
languages.$a = array(array(1,2), array(3,4), 5, 6);
$b = array('a' => 1, 'b' =>2);
We use arrays in our configurations, in passing complex parameters to
functions, fetching information from databases, basically everything. So it
adds up.Some frameworks have somewhat funny attempts to remedy this by
introducing "shortcuts" like this: function a() { return func_get-args();
}. Of course this doesn't work when you need to specify the key name, and
the overhead isn't worth it.It looks as there may not be a specific reason not to allow the JS
syntax as an alternative syntax (while keeping the current one in parallel):$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
There shouldn't be confusion to the parser as the brackets aren't
preceded by an identifier.Was this discussed before on the list?
Regards, Stan Vassilev
--
--
Regards,
Felipe Pena.
Hello Sebastian,
-1, right now we have [] only in read context. And an array will be
constructed with 'array' keyword. Loosing this distinction is a bit of a
draw back for me.
marcus
Wednesday, May 28, 2008, 12:58:24 AM, you wrote:
fyi - i added a RFC
please add your votes
cheers
Sebastian
Sebastian Deutsch schrieb:
dont have karma - but I would love it! so +1 here.
would it make sense to write an RFC?cheers
Sebastian
Stan Vassilev | FM schrieb:
Hi,
I hear this often by other developers and I tend to agree with them,
that arrays are used often, and often nested, so that having a long
syntax for array literals tend to produce less legible code than in
other scriping languages.$a = array(array(1,2), array(3,4), 5, 6);
$b = array('a' => 1, 'b' =>2);
We use arrays in our configurations, in passing complex parameters to
functions, fetching information from databases, basically everything.
So it adds up.Some frameworks have somewhat funny attempts to remedy this by
introducing "shortcuts" like this: function a() { return
func_get-args(); }. Of course this doesn't work when you need to
specify the key name, and the overhead isn't worth it.It looks as there may not be a specific reason not to allow the JS
syntax as an alternative syntax (while keeping the current one in
parallel):$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
There shouldn't be confusion to the parser as the brackets aren't
preceded by an identifier.Was this discussed before on the list?
Regards, Stan Vassilev
Best regards,
Marcus
I've thought about allowing [] for a while and personally have come up
with my own litmus test for new features.
- is the syntax missing from the language?
- if so, does the syntax add missing functionality or significant
maintenance benefit? - if not, does the new syntax add significant value?
#1 no, array() is the same [-1]
#2 not applicable [0]
#3 [-.5]
- can't google []
- makes arrays simpler to type and take up less space
- adds potential for confusion between array access and creation:
$a['hi'];
$a;['hi'];
both are now suddenly valid PHP
- syncs with javascript and other languages
- opens pandoras box - PHP is simpler than Perl because there are not
20 ways of doing the same thing with different punctuation shorthands
So I find #1 is -1, #2 is 0, #3 is about -.5
Although the idea is somewhat attractive, I've found no drawbacks to
array() syntax, and plenty of dangers with adding any new alternate
syntax, and this ultimately makes my vote -1
Greg
hi,
What's the idea behind repeating the same (good or bad) argument
endlessly with more or less prose around them? Thanks for voting at
the end anyway.
I've thought about allowing [] for a while and personally have come up
with my own litmus test for new features.
- is the syntax missing from the language?
- if so, does the syntax add missing functionality or significant
maintenance benefit?- if not, does the new syntax add significant value?
#1 no, array() is the same [-1]
#2 not applicable [0]
#3 [-.5]
- can't google []
- makes arrays simpler to type and take up less space
- adds potential for confusion between array access and creation:
$a['hi'];
$a;['hi'];both are now suddenly valid PHP
- syncs with javascript and other languages
- opens pandoras box - PHP is simpler than Perl because there are not
20 ways of doing the same thing with different punctuation shorthandsSo I find #1 is -1, #2 is 0, #3 is about -.5
Although the idea is somewhat attractive, I've found no drawbacks to
array() syntax, and plenty of dangers with adding any new alternate
syntax, and this ultimately makes my vote -1Greg
--
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
What's the idea behind repeating the same (good or bad) argument
endlessly with more or less prose around them? Thanks for voting at
the end anyway.
It's an important thing that people are be able to show their
choices with proper reasoning. I can only commend Greg for doing so.
Unfortunately, there are too many misguided souls that just want to add
stuff to PHP for no obvious benefit. PHP needs some love to create a
better user experience, nor argument there - however, this love should
to actually fixing the stuff that we have. PDO can use quite some
attention for example. Let's not waste time (and sanity) by adding new
useles constructs that only appeal to some. From what I can see there is
not a major majority in favor - in this case I'd even say that 50%
should not be enough for this **** to get in.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Derick Rethans wrote:
From what I can see there is
not a major majority in favor - in this case I'd even say that 50%
should not be enough for this **** to get in.
I know blog comments are not completely scientific and perhaps not an
accurate representation of the whole commnity. But the comments on my
blog post seem to indicate that the people in the community, that read
planet php, who also felt strong enough about it to comment, seemed to
like it.
http://brian.moonspot.net/2008/05/28/short-array-syntax-for-php/#comments
Again, I know many will think this is horribly innacurate and pointless
because all of these people don't have CVS karma. And even I would take
it with a grain of salt. But I think as Rasmus has said we have to
evolve with the common web developer that is using PHP today.
If it was up to me, none of the overly complicated OOP stuff would have
ever made it in. I find it useless and pointless. You can do all that
with a few functions, IMO. But it was added to make all the Java
refugees happy.
--
Brian Moon (brianlmoon@php.net)
Hello,
On Wed, May 28, 2008 at 12:12 PM, Gregory Beaver greg@chiaraquartet.net
wrote:
I've thought about allowing [] for a while and personally have come up
with my own litmus test for new features.
- is the syntax missing from the language?
- if so, does the syntax add missing functionality or significant
maintenance benefit?- if not, does the new syntax add significant value?
#1 no, array() is the same [-1]
This is not a valid argument, in my opinion.
#2 not applicable [0]
How can you dismiss whether the syntax adds benefit? If a single person
finds it beneficial it has a benefit, maybe not a majority benefit, but a
benefit none the less. Lots of people will find it easier to pick up coming
from other languages.
#3 [-.5]
- can't google []
If we are going to use google search as a determinative for language
decisions we got some major cleanup to do, lets start by removing curly
braces..
- makes arrays simpler to type and take up less space
- adds potential for confusion between array access and creation:
$a['hi'];
$a;['hi'];both are now suddenly valid PHP
As far as $a;[0]; goes, that is just a problem with useless contexts allowed
in PHP. Same can be done for $a;Array(0), which I doubt would cause
debugging problems (i do get your point). Really their are many places for
syntax errors, and php does allow a lot of useless syntax, like:
$a;;;$b;;;$c;;;;{{;;;{{}}}};;;;;;;;;;;;;;; ... that is perfectly valid
code. At the end of the day the developer needs to have sufficient ability
to debug their code.
- syncs with javascript and other languages
- opens pandoras box - PHP is simpler than Perl because there are not
20 ways of doing the same thing with different punctuation shorthands
See my previous post, 20 ways of doing one thing is part of the language
already, and what makes programming interesting.
So I find #1 is -1, #2 is 0, #3 is about -.5
Although the idea is somewhat attractive, I've found no drawbacks to
array() syntax, and plenty of dangers with adding any new alternate
syntax, and this ultimately makes my vote -1
Just my opinion.
-Chris
Hi,
It looks as there may not be a specific reason not to allow the JS
syntax as an alternative syntax (while keeping the current one in parallel):$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
ok, in a previous post I mentioned this was discussed short time ago (in
January to be precise) but well, then once again with more details:
When I learned more about PHP one of the things I learned was that PHP
was proud to be a bit more verbose than other languages while not as
verbose as others. By using the array()-Syntax newcomers had a thing to
look for when reading code which I always saw as a central design
principal of the language.
Now we can change such principals from time to time, the world changes,
so can PHP. But for changing such principals we need a clear consensus
imo. In the January discussion the result was around 50:50 which isn't a
clear consensus. Back then there was a small difference between
"committers" and "non-committers. In the group of the "committers" there
were a few more -1 than +1 votes, within the non-committers-group it was
the other way round (your favorite search engine should give you the
exact numbers, don't have it at hand). Now my second assumption is that
"committers" have thought a little bit more about language than "random"
commenters" of course there are exceptions but I think the general
picture should be like that. So in January this change wasn't accepted.
So, now, less than half a year later the discussion restarts and we
aren't much further, from what I see it still looks like a 50:50 to me -
without "counting".
Now to my own opinion:
I read way more code than I write, code from different people using
different coding styles etc. so I like a more verbose syntax.
johannes
Hello,
On Thu, May 29, 2008 at 11:55 AM, Johannes Schlüter johannes@php.net
wrote:
Hi,
It looks as there may not be a specific reason not to allow the JS
syntax as an alternative syntax (while keeping the current one in
parallel):$a = [[1, 2], [3, 4], 5, 6];
$b = ['a' => 1, 'b' =>2];
ok, in a previous post I mentioned this was discussed short time ago (in
January to be precise) but well, then once again with more details:When I learned more about PHP one of the things I learned was that PHP
was proud to be a bit more verbose than other languages while not as
verbose as others. By using the array()-Syntax newcomers had a thing to
look for when reading code which I always saw as a central design
principal of the language.Now we can change such principals from time to time, the world changes,
so can PHP. But for changing such principals we need a clear consensus
imo. In the January discussion the result was around 50:50 which isn't a
clear consensus. Back then there was a small difference between
"committers" and "non-committers. In the group of the "committers" there
were a few more -1 than +1 votes, within the non-committers-group it was
the other way round (your favorite search engine should give you the
exact numbers, don't have it at hand). Now my second assumption is that
"committers" have thought a little bit more about language than "random"
commenters" of course there are exceptions but I think the general
picture should be like that. So in January this change wasn't accepted.So, now, less than half a year later the discussion restarts and we
aren't much further, from what I see it still looks like a 50:50 to me -
without "counting".Now to my own opinion:
I read way more code than I write, code from different people using
different coding styles etc. so I like a more verbose syntax.
My only question, is what does PHP want. When I say PHP, of course I am
referring to the tens-of-thousands of users that make PHP a success. Lets
remember that "random commenters" which I would like to refer to as PHP's
actual user base, which I would further annotate that the "committers"
graciously power, respectively; In general tend to favor introducing the
syntax. So, if you were to apply that ratio to the tens(hundreds?) of
thousands of people actually using PHP 50:50 does not not seem correct.
Further, we need to vote for the future PHP, people who have not yet learned
PHP, how can this benefit them. We need to also look at other languages, the
most commonly used languages, how will the migration FROM XLANG to PHP be,
as well as ZLANG to PHP. Lets have some true thought and analysis before
another feature is rejected.
I have been watching the mailing list for long as I can remember and seems
that features and such are never truly voted for. Perhaps a PHP.net voting
system should be made, so PHP can progress based off what the community
wants, not what a group of "committers" want. I respect fully the time and
effort put into the project but time to time I see the vote of PHP (in the
afore mentioned context) lost and discounted for.
Just my opinion.
-Chris
On Thu, 2008-05-29 at 13:32 -0700, Chris Stockton wrote:
My only question, is what does PHP want. When I say PHP, of course I
am referring to the tens-of-thousands of users that make PHP a
success. Lets remember that "random commenters" which I would like to
refer to as PHP's actual user base, which I would further annotate
that the "committers" graciously power, respectively; In general tend
to favor introducing the syntax. So, if you were to apply that ratio
to the tens(hundreds?) of thousands of people actually using PHP 50:50
Well, the "commiters" become "commiters" since they show continuing
interest in PHP and spent time to learn about the internals and made
experiences for taking the consequences from "bad" decisions. There are
non-commiters here which are really smart and probably have way more
experience than many others around here but many of the commenters here
seem not to be of that kind, some say "hey, that's fancy new stuff I
want it" but don't think about any consequences ... I simply assume that
the amount of these people is less in the "commiters" group, and well,
it are the "commiters" who will, most likely, maintain the engine over
the nextfew years, non-commiters come and go on this list more
frequently.
Besides the "clue" factor there's another point: Most Contributors do
stuff they need and by chance "users" get it, too. That in the hope
that others contribute, too and create stuff the other one uses. For
most people there's not much reason to maintain stuff they don't need
all they get is a bigger ego. If a "user" wants a feature he should step
up
Oh, and I like that posting from another project's list about that
topic:
http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070607.html
I have been watching the mailing list for long as I can remember and
seems that features and such are never truly voted for. Perhaps a
PHP.net voting system should be made, so PHP can progress based off
what the community wants, not what a group of "committers" want. I
Voting? Oh my.
I don't agree to all stuff in the book, but in general it's a good read:
http://producingoss.com/html-chunk/consensus-democracy.html
respect fully the time and effort put into the project but time to
time I see the vote of PHP (in the afore mentioned context) lost and
discounted for.
Generally speaking: Why should somebody develop and maintain a feature
for free he doesn't want? If a "user" wants a feature they should prove
that they will maintain it in the longer run and provide a patch. Most
stuff in PHP was done since the contributors needed it themselves....
So back to the original topic: In a 50:50 scenario I'd certainly give
more weight to people I know for contributing for a long time than
somebody who just appeared on the list. That's what I said in my
previous mail.
johannes
Hi!
most people there's not much reason to maintain stuff they don't need
all they get is a bigger ego. If a "user" wants a feature he should step
up
In this particular case it doesn't work - one can step up as much as one
wants but if this feature is not accepted then no amount of stepping up
is going to get it into the code. If it is accepted, there would be no
problem making the patch and finding somebody to support it.
Voting? Oh my.
I don't agree to all stuff in the book, but in general it's a good read:
http://producingoss.com/html-chunk/consensus-democracy.html
Well, I agree voting is far from being ideal. Do you have any other
proposal that would allow to arrive to some decision? Like not endlessly
churning the same arguments on the list but have some decision?
So back to the original topic: In a 50:50 scenario I'd certainly give
more weight to people I know for contributing for a long time than
How about Rasmus and Andi? ;) They are both "aye"s.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
So back to the original topic: In a 50:50 scenario I'd certainly give
more weight to people I know for contributing for a long time thanHow about Rasmus and Andi? ;) They are both "aye"s.
I'm probably in the 'nay' camp, but purely because I can't see any reason to
take several years of existing code base and changing it. So as long as no one
is suggesting DROPPING the existing perfectly adequate syntax but rather just
adding something else to slow down processing then I can put up with that. The
accelerator will probably take care of any extra delays caused by all the
additional features that are being added but as soon as something comes up
that is detrimental to existing functional code?
I keep being told - "You don't have to use it" - so as long as that is the
case then I just have to live with the problems of trying to ready updates to
libraries that are not in formats that I am used to :(
PHP6 is going to break a lot of things but I hope THIS is not one of them?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi!
I'm probably in the 'nay' camp, but purely because I can't see any
reason to take several years of existing code base and changing it. So
I wish I had any idea about how we got to changing existing code base.
No one ever suggested removing array() syntax.
syntax but rather just adding something else to slow down processing
Adding one extra clause to parser is not going to slow down anything in
any noticeable sense.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
How about Rasmus and Andi? ;) They are both "aye"s.
And Andrei (heh and me! :-D
--
Pierre
http://blog.thepimp.net | http://www.libgd.org