> Guys, > > Laughter has nothing to do with it. > > However, as discussed between those who attended the meeting > in Paris, goto earned its bad connotations for a reason. It > was agreed that providing a general-purpose C-goto equivalent > is not a good idea because it *will* very quickly lead to > spaghetti coding styles. We also came to the conclusion that > the main use case that is not covered by PHP today is that of > 'centralized' error recovery, which requires forward jumping > only (if it wasn't for that use case, I think we would have > had consensus not to add any type of goto at all). > > So, the logical conclusion appeared to be: > > 1. A forward-jumping construct only, to avoid giving users > too much ammo to shoot themselves in the foot with spaghetti coding. > 2. A construct which is not named 'goto', not because of the > bad connotations (that's actually a good reason to keep it > named 'goto'), but in order to make it clear that it's not > goto, so that nobody expects it to behave like goto in other > languages. > > I'm not sold on reusing the break construct for that, since > we're not really breaking, and I kind of like Ilia's "jump" > idea. Another possibility would be reusing 'continue', which > makes a bit more English sense, even though it's not very > similar to continue's semantics. >
I got a horrid thought that people will end up trying to get around the limitation, abusing the forward only goto and other language constructs to get it todo backward jumps, and you'll have even worse code than with a backward jumping goto. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
