|
AnnMarie Otoole
Addicted scripter
Join date: 6 Jan 2007
Posts: 162
|
08-01-2007 22:17
Why does a state name have to be a literal?
It seems like a simple addition and would save a bunch of idiot scripting.
Instead of 15 lines of code:-
if(fooNumber == 1) state foo1;
if(fooNumber == 2) state foo2;
- -- -
-----
if(fooNumber == 15) state foo15;
etc.,
You could do it in 1 line:-
state "foo"+(string)fooNumber;
The compiler could first check if it is a legitimate literal state and if not, evaluate it and see if the result is a string whose value corresponds to a state name.
True we would lose the error checking for calling state name during compiling and it may have to just fail silently if it got an illegal state name when running but it wouldn't be the only thing that fails silently. The pre-compilation error checking seems simple.
It is nearly a poor man's CASE statement which is seriously lacking.
|
|
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
|
08-01-2007 23:26
I think they didn't do it because state changes are a little more complex than acting as a simple case statement. Perhaps even they saw no need to overcomplicate it, and I doubt they expected it to be used that way.
In fact, using it as one probably would not be advisable, mainly because of the overhead state changes incur, plus the fact that listens, sensorrepeats, etc do not persist across them, and the event queue is flushed as well, so you can lose events.
|
|
Newgate Ludd
Out of Chesse Error
Join date: 8 Apr 2005
Posts: 2,103
|
08-03-2007 14:05
Because you could not determine at compile time if the state being requested exists and since LSL has not exception handlers.....
_____________________
I'm back......
|
|
AnnMarie Otoole
Addicted scripter
Join date: 6 Jan 2007
Posts: 162
|
08-03-2007 18:03
From: Newgate Ludd Because you could not determine at compile time if the state being requested exists and since LSL has not exception handlers..... but there are many things that fail silently without compile warnings. A warning of silent failure for unresolved states should be sufficient. It could abort to the default state. Anyhow, it was just a wish list item that would save a bunch of code in my applicaton. After 47 years of programming, it raises a red flag when I keep typing nearly identical lines of code.  |
|
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
|
08-03-2007 18:05
Yeah, I would expect keypunch to do that to a body.  |
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
08-03-2007 21:12
Each LSL script runs in 16k of memory, that includes bytecode, heap and stack. Adding it would decrease the amount of available memory for the script. This sort of thing isn't possible in the bytecode presently and LL isn't keen on changing the compiler either. This wouldn't be a small change, this would require a major revision to the VM.
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river.
- Cyril Connolly
Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence.
- James Nachtwey
|
|
RobbyRacoon Olmstead
Red warrior is hungry!
Join date: 20 Sep 2006
Posts: 1,821
|
08-03-2007 21:15
From: Strife Onizuka Each LSL script runs in 16k of memory, that includes bytecode, heap and stack. Adding it would decrease the amount of available memory for the script. This sort of thing isn't possible in the bytecode presently and LL isn't keen on changing the compiler either. This wouldn't be a small change, this would require a major revision to the VM. That reminds me... Was it you or Argent working on an optimizing LSL compiler in C#, and how's that going? . |