Difference between revisions of "LSL 101/Global vs Local Variables"

From Second Life Wiki
Jump to: navigation, search
(New page: Category:LSL 101 {{NavNextPrev|prev=Variables|next=Event Handler Parameters}} A variables whose declaration occurs before the word '''default''' is called a '''global''' variable. Gl...)
 
m (<lsl> tag to <source>)
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
[[Category:LSL 101]]
 
[[Category:LSL 101]]
{{NavNextPrev|prev=Variables|next=Event Handler Parameters}}
+
{{NavNextPrev|prev=Using Variables|next=Variable Initialization}}
 +
{{LSL Wikibook Index}}
  
A variables whose declaration occurs before the word '''default''' is called a '''global''' variable.  Global variables are accessible to all event handlers in the script.  But consider this example
+
A variable whose declaration occurs before the word '''default''' is called a '''global''' variable.  Global variables are accessible to all event handlers in the script.  Consider this example
  
<lsl>string RegionName;    // This is a global variable
+
<source lang="lsl2">
 +
string RegionName;    // This is a global variable
 
   
 
   
 
default
 
default
Line 11: Line 13:
 
     {
 
     {
 
           // Store the name of the current sim for later use
 
           // Store the name of the current sim for later use
 +
 
           RegionName = llGetRegionName();
 
           RegionName = llGetRegionName();
 
     }
 
     }
Line 17: Line 20:
 
     {
 
     {
 
           // Announce the region where the script is running
 
           // Announce the region where the script is running
 +
 
           string WelcomePhrase;
 
           string WelcomePhrase;
 
           WelcomePhrase = "Welcome to " + RegionName  + ".";
 
           WelcomePhrase = "Welcome to " + RegionName  + ".";
           llOwnerSay( WelcomePhrase );
+
           llSay(0, WelcomePhrase );
 
     }
 
     }
}</lsl>
+
}</source>
  
 
The only difference between this and the previous example is that we replaced the one line
 
The only difference between this and the previous example is that we replaced the one line
  
<lsl> llOwnerSay( "Welcome to " + RegionName  + ".");</lsl>
+
<source lang="lsl2"> llSay(0, "Welcome to " + RegionName  + ".");</source>
  
 
with the three lines
 
with the three lines
  
<lsl> string WelcomePhrase;
+
<source lang="lsl2"> string WelcomePhrase;
 
  WelcomePhrase = "Welcome to " + RegionName  + ".";
 
  WelcomePhrase = "Welcome to " + RegionName  + ".";
  llOwnerSay( WelcomePhrase );</lsl>
+
  llSay(0, WelcomePhrase );</source>
  
This change doesn't change the result of the script.  But it does break up the one slightly complex line into smaller pieces.  In this case, the one line wasn't complex enough to cause a problem, but scripts that involve more computation can be much easier to read when the computation is broken up into smaller pieces.  To do this, variables with meaningful names can be used to hold the intermediate results.
+
This change doesn't change the way the script behaves.  But it does break up the one slightly complex line into smaller pieces.  In this case, the one line wasn't complex enough to cause a problem, but scripts that involve more computation can be much easier to read when the computation is broken up into smaller pieces.  To do this, variables with meaningful names can be used to hold the intermediate results.
  
 
Let's walk through the execution of the touch_start handler.  The first executable statement is the variable declaration
 
Let's walk through the execution of the touch_start handler.  The first executable statement is the variable declaration
  
<lsl> string WelcomePhrase;</lsl>
+
<source lang="lsl2"> string WelcomePhrase;</source>
  
 
This is called a '''local''' variable because its use is going to be restricted to this event handler.  Just like the global variable ''RegionName'', the declaration causes the sim server to reserve a chunk of memory capable of storing a string and to give that chunk of memory the name ''WelcomePhrase''.  What is different is that this declaration is executed <u>each</u> time the touch_start handler is executed, whereas the global declaration is only executed once.
 
This is called a '''local''' variable because its use is going to be restricted to this event handler.  Just like the global variable ''RegionName'', the declaration causes the sim server to reserve a chunk of memory capable of storing a string and to give that chunk of memory the name ''WelcomePhrase''.  What is different is that this declaration is executed <u>each</u> time the touch_start handler is executed, whereas the global declaration is only executed once.
Line 43: Line 47:
 
The next line
 
The next line
  
<lsl> WelcomePhrase = "Welcome to " + RegionName  + ".";</lsl>
+
<source lang="lsl2"> WelcomePhrase = "Welcome to " + RegionName  + ".";</source>
  
is straighforward.  It creates the string just as before, and then assigns the whole string to the variable ''WelcomePhrase''.  The third line
+
is straightforward.  It creates the string just as before, and then assigns the whole string to the variable ''WelcomePhrase''.  The third line
  
<lsl> llOwnerSay( WelcomePhrase );</lsl>
+
<source lang="lsl2"> llOwnerSay( WelcomePhrase );</source>
  
 
retrieves the value stored in the variable ''WelcomePhrase'' and passes it to ''llOwnerSay''.
 
retrieves the value stored in the variable ''WelcomePhrase'' and passes it to ''llOwnerSay''.
Line 53: Line 57:
 
Note that if we really wanted to, we could break things up into even smaller pieces.  Consider the following fragment.
 
Note that if we really wanted to, we could break things up into even smaller pieces.  Consider the following fragment.
  
<lsl> string WelcomePhrase;
+
<source lang="lsl2"> string WelcomePhrase;
 
  WelcomePhrase = "Welcome to " + RegionName;
 
  WelcomePhrase = "Welcome to " + RegionName;
 
  WelcomePhrase = WelcomePhrase + ".";
 
  WelcomePhrase = WelcomePhrase + ".";
  llOwnerSay( WelcomePhrase );</lsl>
+
  llOwnerSay( WelcomePhrase );</source>
  
This version breaks up the two string concatenations into two separate commands.  The first assignment statement
+
This version breaks up the two string concatenations into two separate commands.  Remember that a *concatenation* is when two strings are joined with a + plus sign.  Thus, the first assignment statement
  
<lsl> WelcomePhrase = "Welcome to " + RegionName;</lsl>
+
<source lang="lsl2"> WelcomePhrase = "Welcome to " + RegionName;</source>
  
 
results in the variable ''WelcomePhrase'' holding the string "Welcome to Ganymede" (assuming that we're executing the script in Ganymede).
 
results in the variable ''WelcomePhrase'' holding the string "Welcome to Ganymede" (assuming that we're executing the script in Ganymede).
Line 66: Line 70:
 
The second assignment statement
 
The second assignment statement
  
<lsl> WelcomePhrase = WelcomePhrase + ".";</lsl>
+
<source lang="lsl2"> WelcomePhrase = WelcomePhrase + ".";</source>
  
 
takes the current value of ''WelcomePhrase'', concatenates the "." and stores the new result back in the the variable ''WelcomePhrase''.  This process of replacing the current value of a variable with a new one is called '''updating''' the variable.
 
takes the current value of ''WelcomePhrase'', concatenates the "." and stores the new result back in the the variable ''WelcomePhrase''.  This process of replacing the current value of a variable with a new one is called '''updating''' the variable.
  
Remember we said that memory was set aside for '''WelcomePhrase''' each time the touch_start handler is executed.  You might think that this would slowly use up the memory that is available to the script.  But this doesn't happen because at the end of the touch_start event handler, the sim "un-reserves" the memory, allowing it to be used again when it is needed for some other purpose.
+
Remember we said that memory was set aside for ''WelcomePhrase'' each time the touch_start handler is executed.  You might think that this would slowly use up the memory that is available to the script.  But this doesn't happen because at the end of the touch_start event handler, the server"un-reserves" the memory, allowing it to be used again when it is needed for some other purpose.
  
 
It is preferable to use local variables instead of global variables any time a value doesn't need to be retained once the event handler completes.  (The reserving and un-reserving of local variables happens so efficiently that it is not a significant contribution to the work the sim server has to perform.)
 
It is preferable to use local variables instead of global variables any time a value doesn't need to be retained once the event handler completes.  (The reserving and un-reserving of local variables happens so efficiently that it is not a significant contribution to the work the sim server has to perform.)
 +
 +
There are other variations on local variables that we will discuss as the need arises. 
 +
 +
'''Please continue the tutorial with [[LSL 101/Variable Initialization|Variable Initialization]] or go back to [[LSL 101/Using Variables | Using Variables]].'''

Latest revision as of 13:42, 24 January 2015

← Using Variables ↑̲  LSL 101  ̲↑ Variable Initialization →

A variable whose declaration occurs before the word default is called a global variable. Global variables are accessible to all event handlers in the script. Consider this example

string RegionName;    // This is a global variable
 
default
{
     state_entry()
     {
          // Store the name of the current sim for later use
 
          RegionName = llGetRegionName();
     }
 
     touch_start( integer num_detected )
     {
          // Announce the region where the script is running
 
          string WelcomePhrase;
          WelcomePhrase = "Welcome to " + RegionName  + ".";
          llSay(0, WelcomePhrase );
     }
}

The only difference between this and the previous example is that we replaced the one line

 llSay(0, "Welcome to " + RegionName  + ".");

with the three lines

 string WelcomePhrase;
 WelcomePhrase = "Welcome to " + RegionName  + ".";
 llSay(0, WelcomePhrase );

This change doesn't change the way the script behaves. But it does break up the one slightly complex line into smaller pieces. In this case, the one line wasn't complex enough to cause a problem, but scripts that involve more computation can be much easier to read when the computation is broken up into smaller pieces. To do this, variables with meaningful names can be used to hold the intermediate results.

Let's walk through the execution of the touch_start handler. The first executable statement is the variable declaration

 string WelcomePhrase;

This is called a local variable because its use is going to be restricted to this event handler. Just like the global variable RegionName, the declaration causes the sim server to reserve a chunk of memory capable of storing a string and to give that chunk of memory the name WelcomePhrase. What is different is that this declaration is executed each time the touch_start handler is executed, whereas the global declaration is only executed once.

The next line

 WelcomePhrase = "Welcome to " + RegionName  + ".";

is straightforward. It creates the string just as before, and then assigns the whole string to the variable WelcomePhrase. The third line

 llOwnerSay( WelcomePhrase );

retrieves the value stored in the variable WelcomePhrase and passes it to llOwnerSay.

Note that if we really wanted to, we could break things up into even smaller pieces. Consider the following fragment.

 string WelcomePhrase;
 WelcomePhrase = "Welcome to " + RegionName;
 WelcomePhrase = WelcomePhrase + ".";
 llOwnerSay( WelcomePhrase );

This version breaks up the two string concatenations into two separate commands. Remember that a *concatenation* is when two strings are joined with a + plus sign. Thus, the first assignment statement

 WelcomePhrase = "Welcome to " + RegionName;

results in the variable WelcomePhrase holding the string "Welcome to Ganymede" (assuming that we're executing the script in Ganymede).

The second assignment statement

 WelcomePhrase = WelcomePhrase + ".";

takes the current value of WelcomePhrase, concatenates the "." and stores the new result back in the the variable WelcomePhrase. This process of replacing the current value of a variable with a new one is called updating the variable.

Remember we said that memory was set aside for WelcomePhrase each time the touch_start handler is executed. You might think that this would slowly use up the memory that is available to the script. But this doesn't happen because at the end of the touch_start event handler, the server"un-reserves" the memory, allowing it to be used again when it is needed for some other purpose.

It is preferable to use local variables instead of global variables any time a value doesn't need to be retained once the event handler completes. (The reserving and un-reserving of local variables happens so efficiently that it is not a significant contribution to the work the sim server has to perform.)

There are other variations on local variables that we will discuss as the need arises.

Please continue the tutorial with Variable Initialization or go back to Using Variables.