Scripting -- new feature to encourage structure and efficiency

As code gets longer, I struggle to keep things structured and under control.

A common problem is that you have several activities being managed, and each one needs code in a number of events. Sometimes multiple scripts helps, but a) this adds to sim load, and b) if activities need to share global variables this gets very hairy very quickly.

What I would like is to be able to put all the code for a given activity in one place for each state. This would make it much easier to understand which chunk is doing which task, and waay much easier to debug when a particular feature mis-behaves.

What this needs is to allow multiple instances of each event within a state. These should be concatenated, so that

default
{
state_entry()
{
llOwnerSay("Hello";
}
state_entry()
{
llOwnerSay("Hello again";
}
}

is the same as:

default
{
state_entry()
{
llOwnerSay("Hello";
llOwnerSay("Hello again";
}
}

(at the moment, the first version doesn't even throw an error -- it just silently overwrites the first event handler code with the second version)

The reason I wanted this was to allow me to do stuff like ...

integer up_time; // in minutes

default
{
//************ Greeting code **************
state_entry()
{
llSay(0,"Hello";
}
touch_start(integer total_number)
{
llSay(0,"I've been touched"
}

// ************ up-time code **************
state_entry()
{
llTimerStart(60.0);
}
timer()
{
up_time+=1;
}
touch_start(integer total_number)
{
llSay(0,"I've been up "+(string)up_time+" minutes";
}

}

OK, that's a trivial example, but you get the idea.

An interesting side-effect of this approach is that it would be possible to merge multiple scripts (provided they don't do state changes) just by a copy and past of the code inside the "default" state. [If scripts use state, then it probably makes sense for them to be in separate files].

I don't think this would be hard to implement. The only really tricky issue is what to do when parameters are quoted with different names in two places (for example
touch_start(integer x){} and touch_start(integer y). Simple solution is just to disallow that and raise an error.

As a further thought, I suppose one could emulate this functionality by using functions:

// ********** code for the 'a' feature **********
a_touch_start(integer count)
{
// do stuff
}
// ...and functions for the other events that a needs ...

// ********** code for the 'b' feature **********
b_touch_start(integer total)
{
// do other stuff
}
// ...and functions for the other events that b needs ...


default
{
touch_start(integer total_number)
{
a_touch_start(total_number)
b_touch_start(total_number)
}
// and other events as required ...
}

Solves most of the problem, but adds more overhead ...

This really seems like a fabulous way to make it harder to debug... event shards all about the place makes it harder to read, and there's the question of which call is executed first between handlers.

Really, why not:

state_entry
{
	 //============================= Task set one
	 llCommandOfSomeKind(stuff, things, items);
	 //============================= Task set two
	 llCommandOfSomeKind(stuff, things, items);
}

which is already there, easier to read and find all the shards, and there's no question about what runs first.

Uh ... I think that this would be a VERY bad idea. Far from encouraging better structure, it would permit very poor programming practices, and promote highly illegible code.

A better way to achieve the kind of "modularity" that Kimbeau is hinting at would be to implement a proper class/object system akin to that of Java or C++. But with only 16k of memory per script ... Can you say HEsAtPack?

I also don't think this is a good idea.

I do, however, think that the parser needs to throw an error if you "override" an event handler by defining it twice. I've occasionally done that by accident, leading to really difficult-to-solve bugs.

Sounds to me like judicious and prudent use of source file formatting, whitespace, and good commenting would have the best effect. Unfortunately, I can't demonstrate using your example, because it contains a logic ambiguity, but let me posit one of my own:

integer up_time; // in minutes

default {
    state_entry() {
        //************ Greeting code **************
        llSay(0,"Hello");

        // ************ up-time code **************
        llTimerStart(60.0);
    }

    touch_start(integer total_number) {
        //************ Greeting code **************
        llSay(0,"I've been touched");

        // ************ up-time code **************
        llSay(0,"I've been up "+(string)up_time+" minutes");
    }

    //************ Uptime update **************
    timer() {
        up_time+=1;
    }
}

It doesn't have exactly what you are looking for in terms of segrating code based on functionality, at least as far as localizing it to one place in the source file. Unfortunately, that's the nature of both procedural programming in general, and event-based programming in particular. Object-oriented programming goes to great lengths to overcome this issue in the direction you are looking for, but as Nynthan pointed out, it has an overhead which is probably too high for the constraints we have to work with.

That said, you should be able to somewhat approximate code localization by segregating related code together in different scripts and using link_messages as a kind of "poor man's RPC". Since OOP is pretty much anti-global scope in nature, you pretty much can turn each script into an object using this method. It's slow and contributes to bloat/lag (heh, welcome to OOP; but I love it anyway ), but it gives you the kind of structural control you are looking for. I have built kind of a framework which uses this method, and it seems to work pretty good, though it does have a few caveats.

That was part of where I was coming from. Since multiple scripts have significant overhead in SL, anything which helps people not to use them ought to be a good idea. But I accept the comments above that I'm really on the wrong track. There are just too many down-sides!

Treating multiple event handlers as an error does sound like a good idea though.