LSL: #include/external functions...

I've read some people suggesting to bring in #include... Partial, this could be usefull to share common settings amongst scripts, but it would be too limited.

Sharing functions/libraries like this is very likely to get someone running out of the space a script may use (16k is it?).

So I'd say, looking back at the older C days, to combine.

1. #include for inclusion of scripts/notecards!
These notecards/scripts could contain:
- constants (#define)
- references (external, see next part) to functions in other scripts

An example:
#define MAX_ITEMS 10
#define MAX_PRICE 100

I'm not sure about variables (that would make things more difficult then actually needed).
Besides, it would make things more complicated then necessary. Personally I like data-hiding as in OO, and thus would not prefer to *share* variables like global variables over more scripts.

2. external keyword
The external references to functions can be much like the definitions given.
Like:
external mylibrary.integer is_in_list(list l,string to_find,integer stride);

This would allow the script having parsed this line to use the function is_in_list like it was
implemented in the current script. The implementation is however in the script mylibrary, also within the prim.

Currently, this function is_in_list is going to be copied/pasted into every script that would have a use for it.

3. Scope
One has to take care of scope. The simples solution would have the same prim as the scope. So a linked prim would not be able to access parent functions and viceversa.

Last, my apologies if this has been discussed before, but I've tried a search for it, but couldn't find anything definate about external (plenty of #include tho) references.

Please discuss/provide feedback.

If you like it, take a vote:
http://secondlife.com/vote/index.php?get_id=1531

To clarify the Scope (after giving it thought):

Consider 2 prims, A and B, where B is linked to A; A the main prim.

Script B1 in B, function foo();
Script B2 in B, function foobar();
Script A1 in A, function foo();
Script A2 in A, function in_list();
Include script/notecard "Configuration" in A, #defines VERSION 1.0 and external ref B.foo() and external ref A2.in_list

Script A1 includes "Configuration"
- Access to VERSION, A2.in_list(); no access to B.foo() different prim)
Script B2 includes "Configuration
- Access to VERSION, B.foo(); no access to A.in_list()

This might be problematic seeing that libraries must be in more then one one prim.

So a little change:
- declare/implement function libraries in the "Configurationcard"
For Linden it means like just puting a function inline with the script that's including the card. Easy to implement and for us scripters, it's easy maintainable.

hey Marcuw -

i've been using the c-preprocessor to assemble my scripts on the client side. this allows me to develop an LSL library without lumping everything into a single file. it also gives me #define macros - which are nice for a simple form of polymorphism.

if you're interested, you can see more here:

http://www.qarl.com/qLab/?p=20


K.

I think Linden's assumption is you'd use link messages for interscript communication, and reading notecards to pull in the equivalent of #defines.