What Use States?

This thread is a re-birth of an earlier one on cleanup in state_exit(). That thread ended in a general trashing of states and LSL states particularly. This bothered me because LSL states IMHO are the only noteworthy thing in LSL. Those of us old enuf to have lived thru all the ineffectual attempts to impose Encapsulation and other Object Oriented concepts on languages not designed for them should find something encouraging about LSL states. So I'm going to throw out some opinions for target practice.

Opinion 1: Even if it's a bug, a timer that survives a state change is a good thing. It allows the implementation of watch-dog functions when a script goes blind because we have coded a dead-end path with no other events armed. So Lindens, if it ain't already, make it official. One resident timer merely needing an active event handler in a state to function.

Opinion 2: LSL states are very weakly implemented. It should be possible to fully encapsulate an activity in a state without the need of global variables or functions, or using multiple scripts. To really encourage OO coding using states, we need another level of scope for variables and functions. Declaration and definition of functions and state variables immediately following the first brace in the state definition should be allowed. A forced march toward OO language like state constructor and destructor should be encouraged.

Opinion 3: Some state specific features are needed. llRemoveAll(), scope sharing through some form of Inheritance or friendship, etc.

Opinion 4: All the above depends on a firm conviction that Objected Oriented programming is innately better than old style programming. We owe it to our kids and grand kids to coerce them into OO style practices before they get ruined. It's a necessary evolutionary step.

Shoramin now covers ears and hides in fox-hole helmet on his butt.

I don't feel that a full OO is good for an interpreted language. LSL is already slow and running very close to the 16k script limit. Full OO would require a compiler that actually compiled the code and not just converting it to byte code. The ways of scripting we use to get around the limitations of LSL were pioneered by PDP programmers et al (reference to using multiple scripts to get around the memory limitations). I'm sorry but the PDP's came before OO.

I would really like to see state variables. It's such a pain when using states to have to use global variables for all cross event communications.

There should be *no* persistant events between states. Timers should be stopped, listens should be silenced, Sensors desensed.

I agree on most of this, although I just wanna toss something out about Object Orientation. What we have here is not OO, except for the technicality that scripts are in multiple "objects". The language itsel fisn't object-oriented by nature. It's actually a refreshingly different paradigm that we don't really have a mainstream name for: state-based programming. I think it has a lot of interesting possibilities for clean, efficient, and beautiful code to solve various problems one is likely to need to use LSL for.

I guess the point of this rant is that OO isn't everything, not by far. I've worked on projects recently (not SL stuff) that worked very much better in a non-object-oriented way than they would have if I'd tried to stick OO in the mix. I've also seen too many projects where OO hindered the design but was required because it's the next big thing or it's "the only way of doing things". I guess what I'm trying to say here is that LSL's states are not, in fact, OO, but instead are a different paradigm, so it can be dangerous to try to apply too many OO concepts as new features.

That said, I really like the state concept, and, in general (in my somewhat limited experience with LSL), they work pretty well and allow for some nice solutions to problems. Making them a little more robust (i.e. if I'm in state foo and I do "state foo;", I'd like to see state_exit() and state_entry() called along with a full cleanup) would be cool.

I am not trying to spam, if I am let me know and I will delete this post. I think state are a great idea. But I have stopped using them. I do every thing in one state , when ever possible. I found by switching states it was possible to lose input from listen.

BTW permissions last between states. But if each sate is separate processes, should they really last?

I've always looked at sls as I would visual basic. Long as we have events like touch, listen, change. I don't know how they could remove global variables. But it would be great if there were state variables. And as long as sls dose not support classes, and over loading I wouldn't want to deal with the hassle of passing on 10-40 variables between each function call.

I was surprised to read in the original thread that timers' current behavior might be a bug. To me, having a timer attached to each script which can be accessed from any state within the script is a good thing. I assume particle systems work the same way (i.e. one per script, any state can start or stop), but I haven't tested it yet.

Besides timers, permissions, and particle systems, I can't think of any other capabilities which would benefit from this kind of relationship to states, but for those three, I think it makes a certain amount of sense.

== danny d.

actually i fairly like the current system, states allowing me to alter completely a script behavior without stupid global variables, i use it more like a script chaging system

for the encapsualtion, i have the habit to use several scripts and to make em communicate using link messages, like you would do with a library

the global timer is good
in fact i would be happy if all behavior activated, like sensors and listens where persisting when state change

I am of the opinion that states are the best thing LSL has going for it, and I use them ALL the time. I have found that segmenting my application into a lot of small scripts with liberal use of states has allowed me to create tight, readable code.

States allow me to limit listen processing, since I often only want to listen for specific msg's in specific states, and I can make assumptions. States give me a nice way to cleanup listens, since they are all deleted on a state transition. States are VERY powerful when used properly.

I concur that state scoped variables and functions would be a great addition, and this could be done in a completely backward compatible fashion, since existing scripts simply don't have any variables or functions declared within a state definition.

States in LSL are your friend...

- Ace

Each state is NOT a separate process!!!!

Each script runs within its own memory context, but all of the states within a script share that context.

- Ace