[gameprogrammer] Re: More scripting engines

At 06:39 PM 24-04-04 +0200, you wrote:
>On Saturday 24 April 2004 17.18, Bernhard Bliem wrote:
>> That's an interesting idea. However, wouldn't a goto be actually
>> sufficient?
>
>Sufficient, but not adequate. In fact, I'm probably not going to 
>support goto at all, considering the horrible mess it tends to create 
>when mixed with higher level flow control constructs. (Etc etc.)
>
>In short, goto is plain evil. :-)

Personally, i suspect brainwashing ;)

Goto can be part of hideous code, no doubt about it. But according to the
NRA, goto's don't hurt programs, it's programmers who hurt programs ;-D

IOW, if a programmer does not think and code clearly, nothing the language
does can save the results, and if (s)he does, (s)he will write good code
whether goto is available or not. A good clean goto with a
sensibly-labelled target in plain view, is far easier to read, support etc.
than the eleventy-deep-nested "break" which the compiler will turn into an
asmb goto anyways. It's better, because it's explicit.

>However, "break <n>", while rather nice and useful in cases, is pretty 
>evil as well. The biggest issue is that you can't clearly see where 
>you land, and it's easy to mix up ordinary {...} blocks with 
>breakable blocks and land totally off without even getting a compiler 
>warning.

Hey, if u have a clear goto label, u see just where u land.

>Of course, there's the alternative of not supporting multilevel break 
>( C/C++), or even not supporting break at all (!) - but then you end 
>up throwing in extra flag variables and stuff to get the job done in 
>real life code. (Or even using goto, if that's available... Ewww.)
>
>So, I figured if I reference outer scopes by name when breaking more 
>than the current level, the code gets more readable, you can't 
>accidentally land on the wrong level, and the risk of breaking stuff 
>when you modify the code is lower.

A close runner-up, IMHO, and rather more tedious to implement.

cheers - grant

Other related posts: