Re: [flexcoders] Re: how to access action script variable data type in mxml

2010-06-16 Thread Oleg Sivokon
Nope, sorry Amy, it's not possible to get the type of a local variable, you
can only get the type of a value it references. Example:

function foo():void {

var bar:IBitmapDrawable = new BitmapData();

}

you can only know what the type of the value is ( BitmapData ) the type of
the bar variable (IBitmapDrawable) may not even exist in the compiled code
- there's no need for it to exist anyway.


RE: [flexcoders] Re: how to access action script variable data type in mxml

2010-06-16 Thread Gordon Smith
I think you're right that you can't find out at runtime that 'bar' was typed as 
IBitmapDrawable. But using IBitmapDrawable as a type annotation does ensure 
that it gets compiled in unless you deliberately exclude it.

Gordon Smith
Adobe Flex SDK Team

From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf 
Of Oleg Sivokon
Sent: Wednesday, June 16, 2010 4:38 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Re: how to access action script variable data type in 
mxml


Nope, sorry Amy, it's not possible to get the type of a local variable, you can 
only get the type of a value it references. Example:

function foo():void {

var bar:IBitmapDrawable = new BitmapData();

}

you can only know what the type of the value is ( BitmapData ) the type of the 
bar variable (IBitmapDrawable) may not even exist in the compiled code - 
there's no need for it to exist anyway.



Re: [flexcoders] Re: how to access action script variable data type in mxml

2010-06-16 Thread Oleg Sivokon
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: Dictionaryint, 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 :)