PHP Short Syntax for Arrays: developers say no.
wiki.php.net
wiki.php.net
The cons seem nowhere near strong enough to counter the fact that the overwhelming majority of users want this syntax, and have been asking for it for years.
that decision, though, is unfortunate IMHO. esp seeing that the userland votes are overwhelmingly pro while the devs are con.
The statement that "It's like they don't even _want_ to fix the language" is inaccurate. It does not relate to the state of things in the real world.
Accusing the developers of some warped intent to keep it in a broken state is an understandable expression of frustration, but it does nothing to advance our discussion and contributes to a misunderstanding of the situation.
Who decided that "<?php echo $variable;?>" is better than "<?=$variable ?>". I think one of their main arguments was that it could conflict with XML / XHTML parsers, but the people who want to parse php files using XHTML parsers are probably in the minority.
Which is why it's being brought up again for 5.4, since this vote took place in 2008.
I really don't see the issue here.
Why does the same criteria not apply to short array syntax? If you don't want to use it, don't use it, but hundreds of thousands of other people likely do want it.
FWIW, I first remember hearing about this in 2003/2004, and at that time I was against it for most of the same reasons I've read in opposition to adding it. Working outside of PHP for some time, I've come to realize the shortsightedness I labored under, and would fully love to have this.
I'm not 100% sure the votes on that page are from May 2011 - it's hard to tell for sure.
goto is a limited goto, and the reasoning for it's inclusion makes sense when you consider the other forms of limited goto already in place (breaks, cases, try/catches). It's not an unlimited goto.
I understand GOTO, but the reaction to people who thought it was a bad idea was "don't use it!", ignoring the fact that whether we use it or not, we have to deal with other peoples' code that do use it.
The people shouting "don't use it!" are thinking of a limitless goto. It's a shame, but not surprising really.
"Other than a couple of grumpy old-timers, I think we are in agreement that we should add a short array syntax. Whether we should extend that to also add a short object syntax is a secondary question." (http://news.php.net/php.internals/52597)
Contra
...
Not searchable through search engines
Considering how widely taught (and self-taught) PHP is, I think that's pretty important, if only from a business perspective―if people don't learn your language, they don't buy your licensed books, and they don't need your technical support because they never built anything with it.
Oh, wait...
On the second thought - if PHP would at last consider converting or storing everyhting as an object ("".length or [].walk()), this would cause a problem. Still, see my first sentence.
As far as language design goes though, I'd rather use a language that's optimized for writing code than for searching for it :).
(The "true" causes the value to be returned rather than printed, obviously.)
I think PHP is going to remain all but stagnant until there is a sea change in the core developers. I'm not sure what their true motives are... laziness? underlying dislike for the language? Whatever it is, all they seem to do is swat down every request, even when (as is the case here) the users are _begging_ for it.
It's like if they can come up with any reason at all not to do it, then they don't. "We already use square brackets for other stuff." Give me a f--king break.
Kinda strange that they have both readable and unreadable listed as both pro and con...
I found array_map, array_filter, array_key_exists, array_this, array_that painful to write, but never felt that I was gaining any sort of readability for it.
I mean it as per the definition on wikipedia:
Syntactic sugar is a computer science term that refers to syntax within a programming language that is designed to make things easier to read or to express, while alternative ways of expressing them exist.Concentrations of people who dislike all syntax sugar can be found in the Forth community and concatenative languages in general, Lisp, and to a lesser extent, in the Haskell community. People who think syntax sugar is the answer to everything can be found in the Perl 5 community, and Perl 6 is arguably syntax sugar spun into cotton candy, hardened, and used to build a glorious gossamer castle in the sky, which they are currently working on landing. I have taken this metaphor too far.
$newArray = $array->map("function_name");
Not gonna happen, but would be nice. Any extensions doing this?
I think it would have been a nice addition...
$a1 = [1, 2, 3];
$b1 = ['foo': 'orange', 'bar': 'apple', 'baz': 'lemon'];
$b2 = ['foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon'];
$a1 = array(1, 2, 3);
$b1 = array('foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon');
$b1 = array('foo': 'orange', 'bar': 'apple', 'baz': 'lemon');
It's a shame that PHP does not get better as a language, as from the point of view of deployment and "get things done now" is great.
$foo = array(
'bar' => TRUE,
'baz' => 'socks'
)
$foo = [
'bar': TRUE,
'baz': 'socks'
] $bar = [1, 2, 3];
$foo = {
'bar': TRUE,
'baz': 'socks'
}; array(1, 'bar' => TRUE, 3, 'baz' => 'socks');
$foo = { bar: TRUE, baz: 'socks' };
where keys are unquoted. The less typing the better.
$keyName = "bar"; $array = array($keyName => "baz");
So in that instance it makes sense to force people to quote their keys. Also, bar or baz could be constants.
I know some browsers allow it, but it's not true JSON.
foo = [
'first',
'second',
'third',
]
foo = [ 'first'
, 'second'
, 'third'
]
EDIT: pull unnecessary commentary
$a = array(1,2,3,); works just fine.
edit: ahh, found it. Knew what it was, but not what it was called: http://en.wikipedia.org/wiki/Keyword_argument
Would definitely be a solution to PHP's ridiculous argument ordering inconsistencies.
The most common way that we get to implement (hack) it now is by using an associative array, which then hides parameters in the implementation of the method as opposed to exposing it in the interface which helps both with reading someone elses code as well as provides for parameter initialization and type hinting (which assoc arrays remove).
I agree with you about argument inconsistencies, and named parameters would help with that, but it even goes beyond that, e.g. how many times have you seen this:
function foo($bar = true, $baz = 5, $qux = "change me"){ ... }
foo(true,5,"this is what i wanted to change");
foo(qux="this is what i wanted to change");PHP, like C++, is a big industry dinosaur that can't and won't change.
In my opinion, the best think you could do is create a new language which compiles to PHP. I.e. A coffeescript for PHP. You don't have to "vote" and get stupid arguments against; you don't have to be backward compatible; and you only have great programmers in that project since crappy ones will just continue to use their 1500 lines unmaintainable functions anyway.
And there are a ton of people who can't justify the switching costs of moving to a different language. And true, a lot of us aren't great programmers. So?
Better tools help. And it's perfectly okay to build and improve tools that regular people will use. Even if they won't be creating the Mona Webapp. ;)
It is, unfortunately PHP resists changes that most of the rest of us consider improvements. I think at this point we might be better served by putting our efforts in to replacing PHP rather than improving it. The replacement need not be the ultimate web language, but should try to be a good language while maintaining a low barrier to entry.
Make this happen please. I can't think of a more deserving language and it'd make my day job a lot nicer.
It's being brought forth again for 5.4, and really pushed. Their is a lot of momentum from the community, and even those who voted against it before are changing their mind.
The topic was then resurrected about implementing in the 5.4 release and the objections didn't seem to be as strong this time around.
So the rejected status doesn't mean that it won't happen in 5.4 just that that was the previous status of the changes.
Cons: Unreadable
What does that even mean?
-edit- beaten to the punch on that one!