What I learnt about scope today

Well, all you experienced scripters will roll your eyes about this, but I shall pass it on for anyone else who might not have realized:

If you declare a global variable in a codeblock, the value associated with that codeblock is strictly local.

For example

string gmessage;

default
{
    state_entry()
    {
        string gmessage="I wish I could say this!";
    }

    touch_start(integer total_number)
    {
        llSay(0, gmessage);
    }
}

When the object is touched, gmessage will NOT be valued (still null from the initial declaration), and nothing will be said.

Instead, the state entry section should read

    state_entry()
    {
       gmessage="I wish I could say this!";
    }

}

I ran afoul of this because I initially had a local variable in a block, then wanted to use that variable elsewhere, so I put a global declaration in. Whoops! As a seasoned, RL professional scripter told me last night, "Yeah, it'll do that. You didn't know?"

It's called "name hiding" and there's no way to guard against in it LSL

I would have expected that first code to not compile since the variable is declared twice.

Many languages will allow you to shadow variables like that, as long as the variables are declared in different scopes as this example is.

This is an excellent reason to work on your (or adopt somebody elses) coding style.

How I name things
- SOME_CONSTANT : global variable with a value that never changes
- gSomeGlobal : regular variable with global scope
- someVariable : regular variable with non-global scope

So...

vector RED = <1.0, 0.0, 0.0>;
vector GREEN = <0.0, 1.0, 0.0>;
vector BLUE = <0.0, 0.0, 1.0>;

string gColorName = "Red";
vector gColor;

default
{
    touch_start(integer count)
    {
        string oldName = gColorName;
        vector oldColor = gColor;
        ... // do stuff
    }
}

Thanks, Meade. I like the capitals for global constants. The g in front of global variables I've been using, and it does help.

Where I tripped up was in being sloppy when I decided to use a formally local variable as a global. All I did was add a global declaration, but left the local declaration intact. Then, of course, later when I was trouble shooting the ensuing glitches, I'd completely forgotton I'd done that!

Yes, neatness does count, sometimes

Also, limit the usage of constants and global variables. Ofcourse, there are plenty of reasons sometimes to have them, just verify to yourself that you need that as a constant or global.

Remember that constants don't exist in LSL: they're just variables that take up memory (unlike other languages where the constants are evaluated and replaced at compiletime).

My $0.02

Lyn

Yeah thats a problem I encountered very early as I started scripting BUT theres an easy way to transport variables too, just need to know how.

declare your desired variable in the head like

string globalmessage;

When you catch a message with a listen

listen(integer chn, string name, key id, string localmessage)

and want to use it in another scope you have to put thi line right behind the listen and the variable gets stored into your global variable, do this:

listen(integer chn, string name, key id, string localmessage)
globalmessage = localmessage;

Now you can use your localmessage with the use of globalmessage in any scope.

I know this is very basic knowledge, but for people who just started scripting and try easy things the use of variables in scopes local and global can be confusing.

Its a very good method to alter a variable with different scopes when alot things should have influence on the result, like mathematical operations.

(with the use of lists and llList2Integer for example and catching variables from other scripts or chatcommands)

You sure about that? I thought I saw something about them fixing this recently...

How would they fix it? There's no way to declare a user-defined constant in LSL. The compiler would need to examine the code and see that the 'potential constant' is never on the left side of an assignment (=)... and in that case, treat it as a constant. Maybe that's what it does?

They did in fact state that they were working on constants, including constant folding and other small optimizations. I can't seem to find the link at the moment, but I remember thinking "It's about time".

As for determining whether an identifier is ever used on the left side of an assignment expression, it's a trivial problem easily solved, and anyone with even a quarter of compiler theory under their belt has had to learn it.

.