The Flex 2.0 beta available from Adobe labs introduces a special new datatype in ActionScript 3, the * type. So what is the *, and when should you use it?
Essentially, the * datatype mans "any type." Declaring a variable as type * is functionally the same as leaving it untyped. That is, the following two blocks of code are equivalent:
var x;
var x:*;
Both declare a variable x and will allow it to take on any type. At first glance, it may seem that the * datatype is pretty useless. All it does is add clutter to your code, and make you type more. Omitting the type is easier anyway, right?
Sure, it's easier to leave a variable untyped instead of declaring it as taking any type. However, using the * type has some important advantages:
- In strict compilation mode, type checking is bypassed. This eliminates messages like "variable 'x' has no type declaration" and "return value for function 'foo' has no type declaration".
- Your code communicates its intent, a principal of Extreme Programming.
- Variables of type * can store the value undefined.
On the first point, eliminating these warnings may or may not matter to you. You can even turn strict compilation mode off, in which case this isn't an issue at all. However, using strict mode will greatly improve your ability to catch mistakes. Reducing the amount of warnings that appear can help you spot the "real" trouble spots easier when you don't have to fish through a see of "no type declaration" messages.
On the second point, using a * as the type instead of leaving a variable untyped is better because the * communicates your intent. You're telling everyone looking at your code that "yes, this variable does not have a type on purpose." By leaving a variable untyped, it could mean different things - either you really wanted it untyped (in which case you should use a *), or you just didn't feel like declaring a type because it's easier that way (in which case you really should type the variable to get the full benefits offered by strict typing, including faster execution and help from the compiler).
Another important use case of the * datatype is when you want to store undefined as the value. Because of changes to the language, some datatypes can no longer store the value undefined. For example, consider this ActionScript 2 code:
var x:Number = 17;
x = undefined;
trace( x ); // output: undefined
Attempting to do the same thing in ActionScript 3 yields different results:
var x:Number = 17;
x = undefined;
trace( x ); // output: NaN
In fact, if we switch from a Number to an int, trying to set the value to undefined will cause the variable to take on the default value of 0:
var x:int = 17;
x = undefined;
trace( x ); // output: 0
But what if you actually wanted to be able to store the undefined value? This is akin to C#'s Nullable Types (which rule, by the way). The same type of functionality in ActionScript 3 can only be achieved by replacing the int type with the * type:
var x:* = 17;
x = undefined;
trace( x ); // output: undefined
As you can see, the * type is an important new addition to ActionScript 3, and has many possible uses. Whether you want to delay the type checking until runtime, want to explicitly state that you don't know what the type of the variable is, or you want to be able to store the value undefined as well as valid values, the * type is something that you'll be seeing a lot of in the future.
Now that's cool.
I don't know if they look at the design of haXe from Nicolas Canasse (creator of MTASC) but "untyped" type was a great addition to that language and now seeing Adobe adding it to AS3 just makes me smile :)
I highly doubt they looked at haXe at all, considering ActionScript 3 is aiming to be 100% ECMAScript compliant.
I agree that the * datatype is a great addition though. :-)
yeah the fact that undefined can be stored in it makes it nice but if you declare it as the * type you can use null as well. i think * opens the field a bit to abuse and some bad practises.
the problem with using null vs undefined is that it does react differently. i:number = null == 0
vs i:number = undefined == NaN
this makes me slightly worried as in flex 1.5 null and undefined can be used interchangabily.
IMO undefined should have been chucked and null should have been the standard by now based on this
var o:Object; trace(">>",o); == null
Well, null and undefined really have two different meanings, so it's ok for them to react differently.
Object is the only type that can ever store undefined, and will be undefined by default - setting a variable to undefined will coerce it to the default value for that datatype. For instance, an int will set to 0, a String will be set to null, etc. In AS3 you can't check if a Number type == null because it generates a compile error (something about can't compare unrelated types, I don't recall the exact message).
Remember, the * mean "any type", so of course it leaves it wide open to type a variable any way you want to. , and makes it easy to abuse if you feel so inlined. The key is knowing when to use it, which is what I tried to outline with this entry.
>>Object is the only type that can ever store undefined, and will be undefined by default
this is exactly what i pointed out to you in the last bit of my post, its default value is not undefined its null. the fact that primitives (and here i include number - its a float)reset to a default value is a good thing . if an objects value has to be undefined (an uninitialised reference) then this is currently a bug in AS3
Well...
var o:Object;
trace( o ); // null
trace( o == undefined ); // true
trace( o == null ); // true
trace( undefined == null ); // true
I don't know what's going on behind the scenes, but even setting an object explicitly to undefined outputs null:
var o:Object = undefined;
trace( o ); // null
So, it looks like either there's a bug in AS3, or the docs are wrong (which state Object defaults to undefined): http://livedocs.macromedia.com/labs/1/flex/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001806.html
Perhaps the behavior has changed from earlier builds, but we're going off a tangent here.