Andi Gutmans <[EMAIL PROTECTED]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
