On 12-02-06 04:07 AM, Tim Streater wrote:
On 06 Feb 2012 at 07:47, Adam Richardson<simples...@gmail.com>  wrote:

While not purely focused on PHP, I toss this out to the group because I
believe there are some novel, interesting points regarding the potential
benefits of using the goto construct as implemented in PHP:


Your val_nested() function looks like a straw-man to me. I've not used a goto 
since I stopped writing in FORTRAN in 1978, and not missed it [1]. Neither do I 
ever have deeply nested if-then-else - these are a good source of bugs. I 
suppose the rest of your article might have been dealing with simplifying 
val_nested() but TBH I wasn't interested enough to find out.

[1] Not quite true - a Pascal compiler I once had to use in 1983 lacked a 
return statement, so I had to fake it by putting a 999: label at the end of the 
function and goto-ing to that.

Goto has it's uses, demonizing it due to the poor implementation and misuse of it's same-named historical counterparts is an exercise in closed-mindedness. Goto can really shine in parsers and various other scenarios. While the example shown may be contrived it doesn't miss the point. Since goto cannot jump out of the function nor jump into the function it is well constrained to provide readability while eliminating complexity. Additionally, it is quite likely that it is more optimal. A single jump target versus one or more state variables to control nested conditionals or loops results in faster execution (also important for parsers).

I've had a strong opinion on goto for a very long time. I was one of the proponents who argued on internals for its inclusion several years ago. I stand by its utility and refer the reader to the fact that many open source projects, especially ones that use some kind of parser, have goto hidden within their implementation. You can find it in the C code for the PHP, MySQL, and Apache to name a few easily recognizable projects.

E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to