2.4 On with the Show

Type checking helps us guarantee that a program will run the way we intend it to. To see how, let's return to Example 3-1 in which a programmer mistakenly attempted to invoke indexOf( ) on a numeric value. The source of the programmer's problem was the incorrect assumption that Date.getDay( ) returns a string, when in fact, it returns a number. The programmer originally assigned the return value of getDay( ) to the variable today without specifying today 's datatype:

var today;

today = new Date( ).getDay( );

Because the code doesn't specify the datatype of the variable today , the ActionScript 2.0 compiler has no way of knowing that the programmer expects today to contain a string. The compiler, hence, allows any type of data to be stored in today . The preceding code simply stores the return value of getDay( ) into today . Because the return value of getDay( ) is a number, today stores a number, not a string. This eventually leads to a problem with the program.

In ActionScript 2.0, the programmer can prevent the problem from going unnoticed by declaring the intended datatype of the variable today , as follows (changes shown in bold):

// ":String" is the datatype declaration

var today

:String

;

today = new Date( ).getDay( );

In this case, the programmer is still "wrong." His assumption that getDay( ) returns a string is still a problem, but it is no longer a hidden problem. Because the programmer has stated his assumption and intent, the ActionScript 2.0 compiler dutifully generates this error:

Type mismatch in assignment statement: found Number where String is 

required.

This error message should elicit great joy. Why? Because known errors are usually trivial to fix once you understand the error message. The error message states that the code requires a string but encountered a number instead. We need to work backward to understand the message's meaning. Why did the code "require" a string? It was just obeying the programmer's request! The compiler thinks the code requires a string because (and for no other reason than) the programmer declared today 's datatype as String . The error message tells the programmer that he is breaking his own constraints; the programmer declared a string-only data container (the variable today ) and tried to place a numeric value (the return value of getDay( ) ) into it.

An inexperienced developer might immediately say, "Aha! The problem is that awful number where a string belongs! I must change the number into a string!" Don't fall into that trap, and don't be misled by the error message.

The programmer originally assumed that Date.getDay( ) returns a String when it in fact returns a Number . But the programmer has no control over the value returned by getDay( ) , which is defined by the Date class and not the programmer. So the solution is to accommodate the return value's correct datatype by storing it in a variable of type Number instead of type String . Example 3-2 demonstrates.

Example 3-2. Fixing a datatype mismatch error

// This line declares


today


's type as a


Number.


var today:Number

// Assign the return value of


getDay( )


to


today


. In this version,

// the variable's datatype matches the datatype of the value returned

// by


getDay( )


, so no type mismatch error occurs.

today = new Date( ).getDay( );

  

// Sunday is 0, Monday is 1, ... Friday is 5.

if (today == 5) {

  trace("Looking forward to the weekend!");

}

Example 3-3 demonstrates an alternative case in which the programmer really does need a string for display purposes. As usual, getDay( ) returns a number, so in this case, the programmer must manually convert the number to a human-readable string. The trick is to use the number returned by getDay( ) to extract a string from an array of day names .

Example 3-3. One way to derive a string from a number

// This line declares


today


's type as a


Number


// and assigns the return value of


getDay( )


to


today


.

var today:Number = new Date( ).getDay( );

  

// Populate an array with the names of the days.

var dayNames:Array = ["Sunday", "Monday", "Tuesday", "Wednesday", 

                      "Thursday", "Friday", "Saturday"];

// Make a new variable that stores the human-readable day.

var todayName:String = dayNames[today];



// Display the human-readable day in a text field.

currentDay_txt.text = todayName;

// Display the human-readable day in the Output panel.

trace(todayName);

So there are two ways to solve a type mismatch error. One way is to declare your variable to be of the correct type and write (or rewrite if necessary) your code to deal with the datatype accordingly . The alternative is to write extra code to convert the returned data to the datatype you desire .

Regardless, without ActionScript 2.0's type checking, the original datatype mismatch might have gone unnoticed.

ActionScript 1.0 had no form of type checking whatsoever and generated no type-based errors. This left developers with the arduous chore of hunting down unintentional typos and misuses of objects.

ActionScript 2.0's approach to datatyping is called static typing . In static typing, the datatype of variables and other data containers is fixed at compile time so that the compiler can guarantee the validity of every method called and property accessed in the program. Because datatypes are fixed in a statically typed language, the compiler can say, "I know this variable contains a Date object, and I know that the Date class doesn't define a method by the name geTime( ) (remember our earlier typo?), so I'll warn the programmer with an error message." Handy indeed.

In ActionScript 1.0, methods were often added to a class via the prototype object. This technique is not recognized by the ActionScript 2.0 compiler in most cases. Therefore, if you are compiling code for ActionScript 2.0, invoking a prototype -based method on a variable with a declared datatype may cause a compile-time error. In ActionScript 2.0, there is no way to add a method to most classes at runtime; the practice is considered officially illegitimate. You should define all methods in class files, prior to compiling. See Section 3.4 for exceptions to this rule. See Section 4.1.1 in Chapter 4 for related information.

The converse of static typing is dynamic typing , in which each value is associated with a datatype at runtime, not at compile time. With dynamic typing, data containers such as variables can change datatypes at runtime because type information is associated with each value, not with each data container. In a dynamically typed language, such as Python or Smalltalk, type mismatch errors can occur at runtime but they can't be detected a priori at compile type. ActionScript 2.0 does not provide any dynamic type facilities and generates no runtime type errors. ActionScript 1.0, by contrast, provided no type checking at all and therefore could not be considered statically typed nor dynamically typed ”rather, it was considered untyped . ActionScript 1.0 effectively let you do whatever you wanted with any kind of data. For example, in ActionScript 1.0, you could change the type of a variable from one type to another without errors:

// ActionScript 1.0 code...

var x = 10;         // Look ma, I'm a number!

x = "hello world";  // Now I'm a string!

And you could access a nonexistent method or property without errors:

// ActionScript 1.0 code...

var s = new Sound( );

s.thisMethodDoesntExist( );  // No error in ActionScript 1.0!

As we learned earlier, the preceding code ”without any modifications ”would not cause errors even in ActionScript 2.0! That's because ActionScript 2.0's type checking is an opt-in system. In order to activate type checking, you must specify the datatype of the variable, property, parameter, or return value being used. Hence, to cause the preceding ActionScript 1.0 code to generate helpful errors in ActionScript 2.0, we declare the variables' datatypes, as follows:

// ActionScript 2.0 code...

var x:Number = 10;  // Here,


x


's datatype starts as


Number


.

x = "hello world";  // This attempt to store a string in


x


causes an error!



var s:Sound = new Sound( );

s.thisMethodDoesntExist( );  // ERROR! No such method...



// Here's the output:

**Error** Scene=Scene 1, layer=Layer 1, frame=1:Line 3: Type mismatch in 

assignment statement: found String where Number is required.

x = "hello world";  // This attempt to store a string in


x


causes an error!



**Error** Scene=Scene 1, layer=Layer 1, frame=1:Line 6: There is no method

 with the name 'thisMethodDoesntExist'.

s.thisMethodDoesntExist( );  // ERROR! No such method...

Because ActionScript 2.0 lets you circumvent type checking by omitting type declarations, its specific variety of static typing is called weak static typing , where "weak" means that the language will check for type errors at compile time if told to do so but also offers programmers ways to disable the type checking system. Languages such as Java that do not let the programmer circumvent type checking are called strongly typed . Generally speaking, it pays to develop all ActionScript 2.0 projects with datatyping enabled for all variables, properties, parameters, and return values (i.e., by declaring their types using post-colon syntax). Even when upgrading ActionScript 1.0 code, try to add as much type information as you can; the more information you provide, the more feedback you'll get from the compiler when you do something wrong.

Macromedia's documentation uses the term "strict data typing" to refer to ActionScript's type checking capabilities. Although Macromedia uses "strict" as a synonym for "static," they are not technically the same. So be aware that the terms "strict," "static," and "strong" are often interchanged recklessly in common discussion, as are "weak" and "dynamic."