ActionScript 2 introduced in Flash MX 2004 the idea of strong typing. This consisted of associating the type of data to a variable with the help of the following syntax:

variable:Type

In the following code we try to allocate a string to a variable Number type:

var distance:Number = "150";

The following error was generated in the compilation:

Incompatibility of types in the appointment instruction: String detected instead of the Number.

In ActionScript 3, we benefit of the same verification mechanism for compilation types. By compiling the same code in ActionScript 3 the following error is generated:

1067: Implicit constraint of a String type value to a type without any Number relation.

This behavior is called Precise Mode in Flash CS3 and is maybe deactivated by the ActionScript 3.0 Parameters panel. Through the publication parameters panel then the Flash tab we click on the Parameters button.

We get an ActionScript 3 Parameters panel containing two options linked to errors as seen here:

We see that by default the Precise Mode is activated (we will come back to the Warning mode). If you un-check the Precise Mode checkbox we deactivate the compilation types in order to discover an extremely important behavior brought about by ActionScript 3.

In testing the following code in non-precise mode we can see that there is a compilation error generated:

var distance:Number = "150";

Upon execution, the virtual machine 2 (AVM2) automatically converts the 150 character string into an int type number. In order to verify this automatic conversion we can use the describeType function of the flash.utils package:

var distance:Number = "150";
/* display :
<type name="int" base="Object" isDynamic="false" isFinal="true"
isStatic="false">
<extendsClass type="Object"/>
<constructor>
<parameter index="1" type="*" optional="true"/>
</constructor>
</type>
*/
trace( describeType ( distance ) );

The describeType function returns an XML object describing the variable type. We can see that the name attribute of the node type returns an int. By modifying the character string we get an automatic conversion to the Number type:

var distance:Number = "150.5";
/* display :
<type name="Number" base="Object" isDynamic="false" isFinal="true"
isStatic="false">
<extendsClass type="Object"/>
<constructor>
<parameter index="1" type="*" optional="true"/>
</constructor>
</type>
*/
trace( describeType ( distance ) );

If we try to allocate another type of data to this the virtual machine 2 (AVM2) keeps the Number type and converts the data upon execution. In contrast to the precise mode, the behavior of the type verification cannot be deactivated.

We could therefore conclude from this that it is better to keep the precise mode so as not to be caught out, but certain types of errors cannot be detected by the compiler as they only happen upon execution.

In the following code the compiler doesn’t detect any errors:

var tableData:Array = [ "150", "250" ];
// the entrance of the table is automatically converted into int
var distance:Number = tableData[0];

Upon execution, the character string at index 0 is automatically converted into int. This conversion stays silent as long as it is successful, if necessary an error upon execution is alerted.

In the following code, we try to stock the character string in a MovieClip variable type:

var tableData:Array = [ "clip", "250" ];
// gives an error upon execution
var clip:MovieClip = tableData[0];

Upon execution, the virtual machine 2 (AVM2) tries to convert the MovieClip string and fails, the following execution error is produced:

TypeError: Error #1034: Failure of the type constraint:
conversion of the ‘clip’ in flash.display.MovieClip is impossible.

We can therefore ask ourselves about the interest in a behavior like this, why a virtual machine would struggle to keep execution types and automatically convert data?

Before guaranteeing optimum performances the virtual machine 2 (AVM2) uses types defined by the developer. Therefore when we type a variable the memory occupation is specifically optimized for this type, as well as the processor instructions.

You must therefore not consider the behavior as an inconvenience but as an advantage contributing to better performances.

This behavior differs from ActionScript 2, where the virtual machine 1 (AVM1) dynamically evaluated all execution types, no optimisation was done. The variable type wasn’t just a help to the compilation.

The new thing in ActionScript 3 is therefore the interest in typing upon compilation as well as on execution. By associating a type to a variable in ActionScript 3 we benefit from verification of compilation types and of an optimization of calculations created by the processor and a better memory optimization.

It is therefore essential to always type your variables in ActionScript 3, the performance greatly depends on this. We systematically type our variables throughout all of these articles.

Here is an example which justifies this decision: A simple loop uses an incrementor variable i type int:

var start:Number = getTimer();
for ( var i:int = 0; i< 500000; i++ )
{
}
// display : 5
trace( getTimer() - start );

The loop needs 5 milliseconds to make 500 000 iterations. Without typing of the variable i, the following loop needs 14 times more time to execute:

var start:Number = getTimer();
for ( var i = 0; i< 500000; i++ )
{
}
// display : 72
trace( getTimer() - start );

In the following code the name variable doesn’t have a specific type, the virtual machine should evaluate the type itself which slows down the execution time:

var start:Number = getTimer();
var name = "Bobby";
var nameShortcut:String;
for ( var i:int = 0; i< 500000; i++ )
{
nameShortcut = name.substr ( 0, 3 );
}
// display : 430
trace( getTimer() - start );
// display : Bob
trace ( nameShortcut );

In simply typing the name variable we divide the execution time nearly in half:

var start:Number = getTimer();
var name:String = "Bobby";
var nameShortcut:String;
for ( var i:int = 0; i< 500000; i++ )
{
nameShortcut = name.substr ( 0, 3 );
}
// display : 232
trace( getTimer() - start );
// display : Bob
trace ( nameShortcut );

In the ActionScript 3 Parameters panel we can see a second compilation mode called Warning Mode. This indicates many different types of errors, for example errors linked to code migration.

Suppose that we tried to use the attachMovie method in an ActionScript 3 project:

var ref:MovieClip = this.attachMovie ("clip", "monClip", 0);

Instead of indicating a simple error message the compiler informs us that the code is not compatible with ActionScript 3 and proposes its equivalent to us.

The previous code generates the following error message on compilation:

Warning: 1060: Migration problem: the 'attachMovie' method is no longer taken into account. 
If the name of the MovieClip sub-class is A, use var mc= new
A(); addChild(mc). 
For more information, consult the DisplayObjectContainer class.

The Warning Mode allows the developer to be warned about certain execution behavior. Beware, the warnings don’t stop the compilation code or its execution, but simply warns that the execution result may not be that which you expect.

In the following code a developer trys to store a character string in a Boolean variable type:

var name:Boolean = "Bobby";

Upon compilation, the following warning is displayed:

Warning: 3590: String used when a Boolean value is expected. The expression will be transtyped as Boolean.

It is therefore heavily recommended to keep the Precise Mode as well as the Warning Mode in order to intercept the maximum amount of compilation errors.

As we previously saw, Flash player 9 no longer fails in silence and warns about execution errors. We will look further into this in the next section.

Something to remember

• It is possible to deactivate the verification type on compilation.
• It is not possible to deactivate the verification type on execution.
• Typing in ActionScript 2 is limited to a help on compilation.
• Typing in ActionScript 3 helps the compilation on execution.
• In a performance optimization problem it is recommended to type variables in ActionScript 3.
• It is strongly advised to keep the precise mode as well as the warning mode in order to catch a maximum amount of compilation errors.