In article <Xns### [at] 204213191226>,
 Philippe Lhoste <Phi### [at] GMXnet> wrote:

> #fallthru?
> "Fall through" is a common comment in C code to emphasize the voluntary lack 
> of break. http://www.houghi.org/jargon/fall-through.html
> Mmm, it is even in the documentation :-)

I don't like "thru", and it is a bit long. Maybe #next or #continue 
(continue is used in C for loops, and isn't any shorter, but at least it 
is a complete word)
#carry kind of makes sense, but has other meanings. #nobreak would make 
sense. Or maybe #proceed? (blah)

Maybe require either #end or #break for every case, instead of having 
one be implied. Only backwards incompatible with potential problem 
#switch statements...the only scenes that would have problems are scenes 
that might not work right now.

Maybe an entirely different syntax where each condition is specified as 
part of one statement, something like:
switch(value)
{
    case is 1, is 3, of range 5 to 9:
    {
        ...
    }
    
    else {
        ...
    }
}

The basic idea: the "case" keyword opens a new case, the conditions are 
separate. Could be less verbose than this, and I'm assuming a language 
redesign...
I've been thinking about this kind of thing myself for Sapphire, I don't 
really like the C syntax either.

Another thing: a switch constant with constant cases can be optimized to 
be much faster than the equivalent nested if-else statements. It is less 
flexible though, another conditional might be useful, maybe call it 
"select" instead to differentiate it from the switch statement. (I 
already know about the select() used in functions, I'm assuming it won't 
last much longer)
The main differences from a switch statement would be variables for case 
values and the ability to use boolean expressions instead of just 
matching values. It should be possible to do it using the switch 
keyword, just not doing some optimizations if these features are used, 
but I like the idea of having it be a different control structure.


> Unlikely to happen, as it will break old code.

The POV Team has talked about large changes in the language before. 
Also, this change wouldn't break a huge number of scenes, and those 
would be easy to fix: just remove the #break statements for most #case 
statements. Other changes would require quite a bit more reworking.


> Perhaps it is a good topic for the FAQ, and perhaps the lack of break trap 
> should be emphasized in the documentation (or not?).

I think this would be a good idea if the break syntax is still used.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message