State variables
While all variables that might be used within more than a single state must be global right now, polluting memory statically, there also some problematic situation to purely event driven state scripts, where there is switched between a number of states with only little number of calls to self defined functions. In such case, where there are only very little number of self defined functions that might be called with arguments, data management is, within one and the same state, only solved through static global memory(heap) / variable allocation. A possible solution might be to allow state variables that are declared after the opening brace from a state declaration and which is/are allocated on stack only when the state is active, but removed from memory when a state becomes inactive from switching to another state. If a stack based solution is not conform to compiler design, another solution might be to have a memory layout of heap based state variables, where there is a fixed allocation of the static part of state variables in size of the largest possible set form state variables, that is reused when switching from one state to another. Such a solution of state local variables might help to provide a significant lower memory footprint in event driven multi state scripts.
Example:
<lsl>
// Both variables "x" and "y" refer to the same memory location
// while only one can be referenced when the given state is active
// Overloading of names in sense of C++ must not be implemented if
// this would cause too much problems with the actual given
// LSL compiler.
state default {
integer x = 0; // with scope of default state
state_entry()
{
llOwnerSay( (string)x ); // produces output "0"
llOwnerSay( (string)y ); // produces compiler ERROR !!!
state ExampleState;
}
}
state ExampleState {
integer y = 1; // with scope of "ExampleState" state
state_entry()
{
llOwnerSay( (string)x ); // produces compiler ERROR !!!
llOwnerSay( (string)y ); // produces output "1"
state default;
}
} </lsl> --Eraz Rhode 07:09, 29 May 2007 (PDT)
State functions (methods) would be interesting too. This sort of complication would require some language design (the exact implementation would end up being controversial). -- Strife Onizuka 09:46, 29 May 2007 (PDT)