Well, it's not exactly like that... the type of the local variable is
checked at compile time. Later on local variables kind of "don't exist",
that is the bytecode doesn't have a concept of "get local function variable
strict" because what's used is the address. I.e. take for example something
as simple as this:

var foo:int = 100;
foo++;

will translate into something like:

"push local" 100
"increment by one"

Or, more precisely, let's look at example:

package
{
import flash.display.Sprite;
 public class VarTest extends Sprite
{
public function VarTest()
{
super();
var foo:int = 100; // we declared a local variable
foo++; // performed some operation involving the varible
}
}
}

o...@home:~/flex/sdk/bin$ ./swfdump -abc ./VarTest.swf
<!-- Parsing swf file:/home/oleg/flex/sdk/bin/./VarTest.swf -->
. . .

    function :VarTest:::VarTest():
    maxStack:1 localCount:2 initScopeDepth:9 maxScopeDepth:10
        debugfile     "/home/oleg/projects/Keeper/src;;VarTest.as"
        debugline     7
        getlocal0
        pushscope
        debug         1 4 0 10
        debugline     9
        getlocal0
        constructsuper (0)
        debugline     10
        pushbyte       100
        convert_i
        setlocal1
        debugline     11
        getlocal1
        increment_i
        convert_i
        setlocal1
        debugline     12
        returnvoid
    0 Extras
    0 Traits Entries

Explanation:
grey - the mandatory initialization stuff and debugging information, not
important for our code
blue - the variable declaration part, this place corresponds to var foo:int
= 100;
red - this is where we increment foo.

Now, convert_i opcode converts the *value *into integer, regardless of the
type of the variable. We could omit the type, in that case we would not have
this opcode, but, this would not affect the variable type, because there
"isn't a variable", there is only an address, a register, where we saved the
integer value of 100.
Next, we retrieve the value from register and increment it,
Then, we set back the register. Note, there are no type checking at this
point. We operate on values and the compiler adds the necessary casting /
conversion if required, but there isn't such thing as a local variable
"runtime type information" because, technically, a local variable is purely
a compile time entity. The local variables may not be accessed by any
external code, so, they don't require the type safety as, say, public API
do. More yet, the compiler will convert all operation concerning variables
into series of procedures, which don't require variables as such. It's
easier to imagine this as a kind of an int-hash table, or something more
like: Dictionary<int, Dynamic>, with the difference from a real dictionaty
being that the actual types are verified at compile time, and therefore
there is no point at doing the same verification at runtime. Or, think about
it as passport control at the airport: once before the flight the passports
are verified, but there's no point to verify them again inside the aircraft
because, regardless of what you will discover during the flight, everyone
will lend in the same destination airport :)

Reply via email to