I personally still fail to see a use for it, but here you go: http://www.php.net/goto 
That’s probably one of the few things I like in PHP. It annoys me how so many languages don’t use a prefix for variables. When you have methods, properties, constants and keywords already sharing the same namespace, why would you want to add variables into that mix and just make reading code even harder?
I wish prefixes were used in more languages in general, not just for variables.
$var
#func
^prop
It’s these types of things that allow for better at-a-glance readability of code. Relying on syntax rules alone for determining whether something is a method, class, constant, property, variable or keyword is NOT a user-friendly approach. If prefixes like those examples above were used more often, you could have languages which are faster and easier to read (not necessarily as easy to learn though) and parsers which are more flexible and nimble.
Code isn’t about cleanliness, it’s about readability. People associated neat code with readable code, but fail to see that those are two very distinct and separate things.
With that out of the way, the one thing I think PHP can’t avoid, is a complete re-write of the API. The current API was written in the early days of PHP, when procedural code was all you had. The age of the API really shows, and in is my biggest single gripe with PHP. All others are pale in comparison.
Get IF…THEN and GOTO commands back in somehow!
Odd, doesn’t do that here locally under Xampp under win7, but does on my Debian server…
<?php
echo false,' : ',true;
?>
Win7+XAMPP Outputs “0 : 1”
Debian Server Outputs " : 1"
Interesting, no?
PHP typecasting or lack therein, oh the joys… though I think that’s also an excellent example of why === is important.
<?php
$a='';
$b=0;
$c=false;
if ($a==$c) echo 'a==c<br />'; /* fires */
if ($b==$c) echo 'b==c<br />'; /* fires */
if ($a===$c) echo 'a===c<br />'; /* does not fire */
if ($b===$c) echo 'b===c<br />'; /* does not fire */
?>
Interesting that false returns an empty string on a real server, numeric on XAMPP under windows, and it still doesn’t trip true in either case on a ===. Gotta love that in the background type tracking.
Took this on topic since it illustrates how some changes proposed could have far reaching implications.
I don’t program in PHP, but “->” is atrocous. Use the “.” notation like most languages use.
Jake, what’s your thoughts on the $_REQUEST superglobal, do you think that it should be depreciated and why?
It is always easy to recognize a Wirth devotee 
I too, hate overly terse, unreadable syntax as in C. I chose Modula2 to write and teach to save my sanity.
However . . . I see no problem with curly brackets, they are graphically cleaner than “begin” and “end”
I also don’t mind loose typing. I am careful with how I use variables and if I find some tricksey loose-type enabled operation unresistably clever and efficient, then I comment what I am doing.
No no no, not just because another language does it MOST other languages do it - and for good reason, but the reason isn’t to turn the language into a mashup.
The reason is because it allows for the rewriting of PHP’s dying function library. It is impossible to rewrite the functions as they are due to backwards compatibility.
Sure, it could be left as it is - but why keep imperfections, isn’t that against the point of advancement?
I don’t like many of these suggestions really, mainly because they are all trying to turn PHP into something it isn’t. Why make PHP like JavaScript? What’s the point in using Strings as objects or whatever, just because another language does it? It’d turn PHP into some kind of franken-language, borrowing snippets from everywhere else, and it’s just totally unnecessary.
My only real issue with PHP as it is is the inconsistency in function naming, but I think that’s more of a problem in people’s heads than a real problem - I certainly haven’t found it any harder to learn PHP’s function names than any other language. The fact that most of you moaning about it are able to quote examples from the top of your head shows that it clearly isn’t a problem memorising the names!
A decent IDE solves most of that issue anyway, prompting for parameters etc.
I like ‘->’ for accessing properties/methods, I like $this, I like . as concatenate…
The only really sensible suggestion of being able dereference arrays when being returned by a function eg function_name()[3] looks like it has already been implemented anyway.
[ot][indent]Quote deathshadow60:
$a=1;
$b=false;
if ($a=$b) { echo ‘Test’; } else echo $a;
/* echo’s out 0 */[/indent]
Not exactly; there would be no output. When echoing the value of $a, its string representation is used which in this case is an empty string. That said, other than giving the wrong outputted value, your explanation (which is what was really important) is fine.
[/ot]
Oh, and I like curly braces - there is no problem seeing what is missing if code is formatted properly, or you use an IDE with bracket highlighting - problem solved. I comment most of my closing braces anyway with what they relate to - eg }//if, }//foreach etc
I like this idea too. For arrays it would also be handy (which you already wrote ;)):
$arr = [1, "abc"];
$arr.sort();
echo $arr.pop();
So the general feeling is that the string functions (and array functions etc) need rewriting. Unfortunately that would break backwards compatibility - so my suggestion would be an entirely new library.
I’d like strings etc to act as native objects.:
$something = 'Hello world';
$something = $something->replace('w', 'W');
And of course a static version:
$something = string::replace('Hello world', 'w', 'W');
[ot]
Well anyone who could deserves a medal or something. But it’s entirely irrelevant; average servers have giga-terabytes of storage and gigabytes of RAM, not to mention multiple processing cores. The 20th century, you gotta love it ;)[/ot]
Just awesome, someone had to say it.
You guys covered the primary thing that bothers me ->. I would like to replace that with a single character and I would be mostly happy. Perhaps there are other things but that is primarily the one I constantly want to change.
The other thing I would like to see that isn’t syntax specific but feature is named parameters like python.
I see where you some of you are coming from with self:: to access static methods. However, I don’t really use static methods and properties all that often for that really to be an issue for me.
None the less, going back to my initial response dot notion would make me very happy. Most of my assignments tend to require transitioning between JavScript and PHP. So having a similar way to access methods and properties would result in less stupid little syntax errors such as; using -> in JS or . in PHP.
I think its really easy to take this to far though. There are really only a couple of things that I think would be beneficial to change. Once you start modifying everything you end up with what looks to be a mess. Especially when you start abbreviating things and using characters to denote access. Although that may seem like a good idea its going to make everything more difficult to read and understand. That is probably especially true for beginners.
One thing someone did mention perhaps not in this thread is standardizing the function signatures. At least to the point where if two functions accept a needle and a haystack the signature is the same. Although, named parameters could possibly fix that issue.
I really dislike all the suggestions for shorthand code. Shorthand is bad. Replacing current language constructs such as $this with one character make for incredibly hard to read code for anyone looking at it. Especially when they would sometimes see the short hand and sometimes see the long hand. What would happen anyway is that someone would write an article showing that one was 0.0000000002ms faster and that would become the convention (see single quotes).
Look at perl’s lovely incomprehensible two letter function names. Shorthand is bad. It makes the language more difficult to learn.
(xkcd 386 applies, of course)
My biggest gripe with PHP is as others have said, inconsistent arguments along with inconsistent function names “strpos()” and “str_replace()” of course base64_encode() and urlencode() are equally annoying. Seriously they need to just make everything work without underscores and it would fix it.
Already in for the control structures (if, while, for etc.) : http://www.php.net/manual/en/control-structures.alternative-syntax.php which is very usefull when using php as a template language.
Well, PHP does offer certain alternative syntax.
As for equals - I like it. There are 3 equals variations, assignment (=), loose comparison (==) and strict comparison (===). All of these have their uses, even in an if statement.
For example, statements which assign values and check them at the same time, for example:
while($row = $Query->Next()){
where $Query->Next is a method to retrieve the next row. When the row is up, it returns false and therefore the loop terminates.
Another example:
if(false !== ($Position = strpos(....))){
So I like the C-style approach to those operators.
I do agree with joebert about the + operator. The only place I could see a downfall is if two strings are numerical - how would the parser know what to do?
I used to think that way when I was coming from other languages to C syntax two decades ago, and felt that way again a decade ago when I started using PHP.
In the case of all C syntax languages there is a functional difference between them that you can’t trust a compiler to do. You will realize this the moment you start dealing with returned values from functions and explicit exit values.
For example, the PDOStatement object has a FETCH method. This method returns an array consisting of a result row, or false if no more records are present.
The assignment operator (=) can be used then in your while:
while ($item=$qHandle->fetch()) {
echo $item['name'],'<br />';
}
If you made = only behave as == inside conditionals, you’d end up having to code that:
$item=$qHandle->fetch();
while ($item!=false) {
echo $item['name'],'<br />';
$item=$qHandle->fetch();
}
So there is a legitimate reason for = to always be an assignment operator that returns the result as a conditional. For your consideration:
$a=1;
$b=false;
if ($a=$b) { echo ‘Test’; } else echo $a;
/* echo’s out 0 */
Why does it output zero? because $a was assigned to the value of B, false, zero… The ‘test’ echo will never run becuase $b is false, the value of the assignment is what the if statement checks against. change $b to true, and it will echo out ‘test’.
=== is also important, especially in PHP as opposed to languages like C which have strict typecasting.
Consider this:
$t=0;
if ($t==false) echo ‘0 = generic false<br />’;
if ($t===false) echo ‘0 = specific false<br />’;
/* second IF will not fire */
$t=false;
if ($t==false) echo ‘false = generic false<br />’;
if ($t===false) echo ‘false = specific false<br />’;
/* both IF will fire */
A specific comparison “===” of zero to false is always false, a generic “==” comparison of zero to false is always true… While PHP lacks strict typecasting it does track type silently in the background. This is often important if you have functions that can return zero OR false. Without strict typecasting this is the only way to differentiate zero, false, and empty string, an empty array, or null apart from each-other.
Again, something that without strict typecasting there’s no way for the INTERPRETER to do.
INTERPRETER my good man, INTERPRETER. PHP is an INTERPRETED language, not a compiled one.
I think that’s where a lot of the attitude on things like that comes from, people keep thinking about php like it was a compiled language - it isn’t, and interpreted languages need different optimizations to perform well. See the difference between interpreted line numbered basic and compiled basic. Line numbers, differentiating strings from floats using $ and forcing one digit variable names made interpreted basic remarkably fast for an interpreted language under extreme memory constraints. More modern line-numberless basic with long variable names means building a symbol table, having a pre-bytecode compiler, manually marking entry points… You wouldn’t be able to do all that in 8 to 12k of ROM with 4k of RAM.
Many of the things people list as PHP’s strengths (untyped variables, custom array indexes) are also a weakness that resulted in many of the more unusual language syntax decisions.
That’s why one change is a wish and never going to be practical, and the other is something I’d like to see. Changing to dot syntax is never going to be practical.
On the other hand, a legacy namespace arrangement could be installed.
I get really annyed with eople who want to change the language just so that they can type in fewer characters. They think it would make them more efficient, but they are totally missing the point - program code is designed to the read by humans more than it is to be executed by a computer, so making code MORE readable instead of LESS readable shoud be the goal. My first language was COBOL, so I know about reading and writing verbose code. I also did some assembler, so I also know abut reading/writing code that is nothing but short symbols.
My biggest peeve with PHP is with function braces. I don’t like having ‘}’ as the end marker for every single function. I much prefer the COBOL syntax where every function (or ‘verb’ in COBOL) has its own ‘end’ marker. Thus IF would have ENDIF, SWITCH would have ENDSWITCH, WHILE would have ENDWHILE, etc. This would solve the current problem where you have a missing ‘}’ in your code, and the compiler can’t report the error until it gets to the end of the file. How long does it take to work out exactly where the problem lies? With a proper end marker it could detect the problem sooner and report it in the correct place.
My second biggest peeve is the difference between ‘=’ (assignment) and ‘==’ (test for equality). How many people have been caught out writing ‘if ($a = $b)’ instead of ‘if ($a == $b)’? If the compiler writer cannot work out if the ‘=’ symbol is being used within a condition or not then he shouldn’t be writing compilers.