In reference to Sara's patch to implement GOTO in PHP:
It saddens me that people are so easily brainwashed by their teachers/peers. Sure, from a high level perspective you don't need a GOTO statement, and the argument that it, when misued, can lead to unreadable code is a good one.
However, I feel that the inverse argument can also be true: complex code with lots of nested if statements and control loops can be also be hard to follow when you need to "get out of jail" fast. Without goto you often need to resort to tricks (in C) such as "do { ... break; ... while (0)", or if you have nested switch's inside loops, create a flag variable and take several steps out of each nesting level. There is no way in hell you can convince anyone of sound mind that those tricks make the control flow easier to understand than a GOTO.
No doubt the anti-goto brigade will campaign that the code could be split up into different functions etc. etc. etc., but it is quite often the case that real programmers need to have this stuff in one function; just take a look at kernel code written in C, for example.
Arguments against GOTO on the following grounds are, IMO, just a bit short-sighted:
- I think GOTO is bad because some guy wrote a paper on it
- I was taught not to use it. (But don't know why; it's supposed to be bad, or something).
- I was taught not to use it because you can use something else.
- You can use exceptions instead; who cares about performance
Regardless of who wrote the paper, or what you were taught, or your disregard for performance (which does have a big impact in the real world; Exceptions are expensive), GOTO is sometimes needed to get the most out of your code. I'll even go so far as to say that most of the people making these anti-goto comments have no practical experience either of using goto, or with dealing with someone elses misuse of goto; if you don't have experience, please shut the hell up :-)
GOTO is one of those tools that you don't always need, and one where it is hard to define precisely when you should use it (<insert anecdote about professor who determined only one extremely rare case you can't handle without goto>). It boils down to what is appropriate for the task (and language) at hand.
Use your brain and evaluate the project--don't just blindly follow what others have said in the past; make up your own mind. If you truly believe that a goto makes a certain section of code more readable, go ahead and use it. If you deduce from benchmarks that exceptions, nested loops with flag variables or whatever are too slow or otherwise too expensive, you have have a perfectly valid reason to use a goto instead.
I'll sum up with a "GOTO doesn't kill code, bad programmers do". Just because misuse of GOTO can be harmful, it doesn't mean that it shouldn't be part of your toolbox, and for that reason I would welcome a GOTO statement in PHP.
Wez Furlong in
PHP.
Here we are, fighting for respectability with a decent object model in php5, and now you are going to have people looking down their noses at us for having GOTO in php ;) The shame.
jsweat_php:
Did you even read Wez's article? Or are you saying that you are proud of your off-hand dismissals?
For the record everyone:
I've never had a need for gotos either. This feature was never about need. It's about the open source process. Here's a piece of functionality that some people would like to use, so how about letting them use it?
The real shame is the guys like Sweat and Moore are afraid of what the Java elite will think of them. C destroyed Pascal by ignoring just that kind of thinking and focusing on being useful.
I think that goto might just be one more reason why PHP5 is better than Java.
C# has goto and even allows you to "goto case label;" and "goto default;" for branching within a switch statement See: "C# Goto" ("http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_8_9_3.asp"). Now that is powerful and cool.
You don't have to use goto, but there are several circumstances (expecially in interpreted languages) where goto is clearer and perfoms better than either the structured programming statements or exceptions.
I think an interesting addition to the PHP goto would be to add a parameter like break has, but to limit how many nested enclosing structures can be jumped out of. It would default to 0 for the whole function/program, but could give an error/warning if set > 0.
For the record I did read Wez's post.
I also include a wink emoticon in the comment, which is a clue that IT WAS A JOKE!
You seem a bit overly sensative on the issue.
Don't think the patch goes far enough, it should also allow computed gotos. {phpcode goto $label; etc
This would help the linear performance of the PHPs switch() statement (where time is proportional to the number of case labels).
Currently working on a project that has 300+ case labels (and is likely too rise). This PHP is computer generated and not handwritten, (Think YACC), so the old maintenance/spaghetti argument is a non-starter.
Even experimented with using an array of functions such like
$jumpTable = array(
create_function('$a,$b', 'return $a+$b;'),
create_function('$a,$b', 'return $a-b;'),
create_function('$a,$b', 'return $a*$b;'),
create_function('$a,$b', 'return $a/$b;'),
create_function('$a,$b', 'return $a%$b;'));
and using
$jumpTable[$i]($a, $b);
appears to perform better than PHP switch statement, so a computed goto should be even faster.
Just noticed the patch does do computed gotos.. ignore last post ;)
Steve McConnell has a chapter on Go To in his classic "Code Complete". It gives both sides equal time and presents their arguments. It even talks about the phony goto debates, he presents the handling of errors with and without gotos. He shows how most gotos can be replaced with code that is easier on the writer/reader of the code, and he finally concludes:
"In the remaining one case out of 100 in which a goto is a legitimate solution to the problem, document it clearly and use it. [...] But keep your mind open to gotoless apporaches suggested by other programmers. They might see something you don't."
I found that after reading the chapter I had no problems refraining myself from entering any Goto-Debate again. (well, I am not sure wether this counts...)
Hi.
There are some really silly comments on this posting. The GOTO opposers have very good reasons for their stance. Attempts to shoot the messengers by labelling them as people parroting dogma is both uncalled for and just plain wrong. Jeff in particular has a very large amount of experience in maintaining long lived applications and he clearly stated his reasoning in his posts. And no one could accuse Jeff of being a Java wannabe.
There are good reasons why GOTO is fast disappearing off the face of the earth. Most experienced OO practitioners keep their methods short and if they want to blow out the stack they sparingly use exceptions.
A cry to performance is lame as if CPU performance were an issue you wouldn't be using an interpreted language like PHP. Other kinds of performance issues are best tackled with well factored code anyway. The C++ STL for example allows usage of appropriate algorithms for a task by making them plug-compatible. The STL also keeps everything exception safe. Try doing that with GOTOs :(.
Why when PHP is stripping junk out, like superfluous ampersands and umpteen case variations, does it have to put an equal amount of junk back in?
Not only the silly "final" keyword, universally hated amongst Java developers, but now we have GOTO, universally hated by developers who have to maintain code. Just because you can put a feature in does not mean you should. We already have a kitchen sink language and it's called Perl. PHP has destroyed Perl in the web arena and Python is busy eradicating it from the Unix/GUI arena as well.
Simplicity works better. Clutter diminishes the value of the stuff you already have and makes the language harder to extend in the future. Low grade features reduce the utility of a language by increasing the cognitive load, the documentation and the learning curve. If something is used rarely, or worse if there are far better ways of doing things, it should be removed. The language will be better for it.
yours, Marcus
Why? Because it's harmless. Don't give me this "unmaintainability" argument all over again. It holds about as much water as a swizel stick. I'm tired of hearing it.
Why not? Because it's insipid and unnecessary. There are hacks that give the procedural programmer the same effects, the oop coder will never deign acknowledge its existence, and the high-performance coder has already ported that loop to C.
How? Implementation two is up at http://pecl.org I'll resist the urge to call it castrated since the scope control enforced was necessary and the run-time evaluation was a sight silly to start with.
"A cry to performance is lame as if CPU performance were an issue
you wouldn't be using an interpreted language like PHP"
Think about it; PHP is "fast enough" in most places, but there are always going to performance critical sections that need that little extra boost. Are you seriously suggesting that it is better to choose another language than to make the current one, which is otherwise ideal, go faster in those critical sections?
"There are good reasons why GOTO is fast disappearing off
the face of the earth."
Is it? Did you try grepping through the sources for the software that you have installed on your system for the keyword "goto"? Do you have statistics to back up your claim that it is in decline?
I'll re-jig my analogy now: rather than equating GOTO to guns, I'll equate it to a knife. An inexperienced user can cut themselves with it, but a skilled user can employ the knife to carve a work of art.
Just because there is a learning curve in knife wielding, should we deny the more skilled people the ability to carve their works of art?
Wez Furlong in
Comment.
Hi...
OK, I just grepped all the .py and the .rb files on my linux box and found precisely none.
Your performance argument is lame. You will gain a few percent at best in a few very obscure and pathological situations by adding GOTO. Every performance problem I have ever run across has required order of magnitude improvements that have required more radical solutions than script twiddling.
The extra clutter of multiple ways of doing things hampers the experienced developers as much as the beginners, who will be punting anyway. It hampers in automated maintanence of software and tool development for a start. I wouldn't fancy writing a refactoring tool for a language with GOTOs all over the place :(.
It hurts PHP too. That's another feature that has to be maintained, documented, tested and bug-fixed. That's time that could be spent optimising PHP, assuming that the GOTO code doesn't get in the way of such optimisations.
If you want to keep enterprise level developers within the PHP community, PHP is currently failing at this, then you need to give them features that are useful. Say namespaces.
GOTO isn't a craft knife, it's a hatchet from the days when that was the only sharp instrument available.
yours, Marcus
I have lots of code that really would benefit in readability and probably speed too if we had goto in PHP. It's a pre-parser that converts a file that can be written by humans and that are easy to understand into another file that is easy and fast to parse with PHP. The original files are fast to parse too, but they shouldn't change that often and are used quite a lot, so pre-parse-transformation should make the whole application much faster.
The bad thing with it is that the code is really unreadable as it is now with nested loops and breaks in different levels to emulate goto and did I mention that there are lots and lots of if-statements there too ? Each breaking the loops in different ways.
I know, I know, everyone isn't writing a parser, but obviously a lot of people do, but there are other things too that could use goto to make the code faster and/or easier to understand.
If you want to keep enterprise level developers within the PHP community, PHP is currently failing at this,
I don't think that this is accurate. PHP is doing pretty well in the corporate world. The reason for ASP and JSP to maintain a strong position in certain markets has nothing to do with the language but with the type of contract/partnership/corporate mambo in that particular field e.g. banks in Switzerland use JSP for the native SSL support and the partnership between HP and Sun for tailored solutions (if you are a bank you need someone to sue when things go awry).
So please don't use your argument against the GOTO, for which I am certainly +1, to quote inaccurate details about PHP adoption by "enterprised level developers".
If you don't like it, don't use it. The maintainability issue doesn't really make sense to me.
Dear Wez,
A complete newby, I am writing an application for me, to be used and maintained by me, using Php, HTML, MySQL, and some javascript. Today was the first time I needed a goto, and I was amazed to find it doesn't exist in Php. It would have been very useful. I think really it is my own business if I write spaghetti code... As it is, I had to make an unusually complex loop, using control variables which were themselves modified by developments within the loop. I think a goto would have been much easier to use in this instance, easier to maintain, and less time consuming. I think keeping goto out of php is an undemocratic attitude, which doesn't recognise that different people have different programming styles. People who don't like gotos need not use them! Of course I would not use a goto to send execution into the middle of a loop, and if I did, I would be the only one to suffer the consequences.
Hopefully goto will be added to Php 6.0!
Yours,
Tristram Shorter
tdshorte@hotmail.com
(Concepcion, Chile)