Re: GOTO operator

Andi Gutmans <andi@zend.com> writes: > I don't think we should be using computed targets. It'd be more of a > nightmare than sexy. I prefer doing as much at compile-time as possible and > I don't think that allowing indirect goto's would lead to anything than > chaos. Most arguments in favor of goto were for circumstances where this > would not be required. (And yes, even if we pre-compute what we can and add > the hash and opcode for the instances we can't pre-compute I think it's a > very bad idea). I feel about 1000 times stronger about that than goto :) If you really, really, really wanted to do such a thing, you could still do: eval("goto foo$bar;"); to get the same effect, right? Just to add my 2 cents, I "grew up" in the early days of structured programming, while Pascal was gaining in popularity. I was taught to never use goto. I've been developing code for over 25 years now, and although I still tend not to use goto (by its various names) in any of the many languages I use (other than possibly assembly language :-), I do find occasional appropriate use for it, particularly for error handling. In fact, some of my recent PHP development could have benefited in simplicity of code by having goto available. I vote +1 for goto with static labels (computed at compile time), and -1 for dynamic labels. I would, however, like to see the above eval kludge work, for consistency of the eval operation. Derrell