[gameprogrammer] Re: More scripting engines

At 09:33 AM 29-04-04 -0500, you wrote:
>On Mon, 2004-04-26 at 01:41, grant hallman wrote:
>> 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.
>
>Implementing a goto into a block structured language is a real pain.
>Gotos always cross block boundaries and interfere with variable scope.
>So, a goto has to clean up the stack for the appropriate number of
>levels and then do the jump. It is hard to handle properly in C. In
>languages with scope exit rules for invoking destructors, like C++, goto
>become a serious implementation problem.

Yikes, who uses gotos that way? I'd think a goto statement would be
restricted to targets within the same block(s), which should avoid entirely
those issues. 

It's a mixed bag, and while gotos can be misused, a break deeply nested in
a complex structure can be just as deadly. But the bigger point is, their
use is a style issue. It's a language's job to offer features, not to try
to impose a programming style. That's just annoying, and leads to even
clumsier workarounds. If OO had lived up to the promises of its early
advocates to impose good style, we'd live in a better, more robust, more
efficient programming world. It doesn't work.

cheers - grant

Other related posts: