On Mon, Feb 6, 2012 at 10:05 AM, Robert Cummings <robert@xxxxxxxxxxxxx>wrote: > On 12-02-06 04:07 AM, Tim Streater wrote: > >> On 06 Feb 2012 at 07:47, Adam Richardson<simpleshot@gmail.**com<simpleshot@xxxxxxxxx>> >> 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: >>> >>> http://adamjonrichardson.com/**2012/02/06/long-live-the-goto-** >>> statement/<http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/> >>> >> >> 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. > > Cheers, > Rob. All excellent points, Robert. Tim mentioned that my example was a straw-man, and you mentioned it was contrived. Actually, it's a refactoring of a real function in my web framework that I've committed to trunk and going to use for a while (it's functionally inspired, and having the ability to store and retrieve immutable values is quite handy in this situation.) I like experimenting with different approaches (my background is in cognitive psychology), and there's certainly research to show that deeply nested ifs are problematic, cognitively speaking. Then, there are the other techniques mentioned in the blog post to deal with them (guard clauses, pulling out functions, grouping conditions), but they have they're issues, too, in terms of processing (they can hurt proximity of related concepts, forcing programmers to work against the mental model they've built up of a problem, etc.) There are going to be issues with the goto approach I took to refactoring the function, too, but I'm keenly interested in playing around with it a while and letting the evidence accrue over time. I've read many, many sources that seem to reject ANY approach using GOTO even without properly evaluating its use within a language like PHP that offers some beneficial restrictions. Thanks for the insights (and I'm glad you pushed for the construct :) Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
