"Adam Richardson" <simpleshot@xxxxxxxxx> wrote in message news:CAC6CJqZ5WKu8C9RuQgC4rqg5cQ35a-LFs1rrYOs3wTfyS6rnVw@xxxxxxxxxxxxxx... > 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 > The use of goto was acceptable in the early days of computer programming. It was a major part of it in fact. I believe that the trend to remove them from usage was because of that very thing. The early programs naturally had to go thru improvements & maintenance but a new generation of programmers came along and that was when the problem with GoTos was realized. It was difficult if not impossible to follow a process completely through so that one could implement a change easily and in the end people unfamiliar with the entire program were forced to put code into multiple spots to ensure that the change they were trying to implement got hit in all the correct circumstances. Gotos allow for too much flexibility and open up diverging paths in the flow of the process. Sure - it works for the original developer, but code must be seen as not the work of one author but as a product that can later be modified/improved/corrected by future authors. Sure - you can say that the life of a specific program/module may not be that long in today's fast-paced changing technologies, but the same argument will be had no matter what is in use on any given day. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
