Ok, no, I really don't.
[Disclaimer: Flash is uber-good. It really is. Like anything that is uber-good, however, there are always going to be little imperfections that serve to frustrate. Which is what I'm talking about. Frustration. Really, I love Flash. We go way back. I think she can take it.]
Flash MX 2004 added type-safety - to a degree. We all know that as soon as we use an Array, for example, our typing is out the window. What many people don't know (and what some who do know consistently forget or ignore), is that on a timeline in Flash, type-safety is not what it should be.
Take this fictitious class, for example:
-
class jn.Jabberwocky extends Object {
-
public static function Wockit( value:String ) : String {
-
return value.toUpperCase();
-
}
-
-
// don't allow instances to be created
-
// this class only contains static members
-
private function Jabberwocky() {}
-
}
Now, on a timeline somewhere:
-
import jn.Jabberwocky;
-
-
var str:String = "This parrot is deceased. Expired. What we have here is an ex-parrot.";
-
var wocked:String = Jabberwocky.Wockt( str );
-
-
trace( wocked );
If you run that, you should see 'undefined' in the trace window. Why?
Because Flash didn't generate a compile error, even though there is no Wockt method on the Jabberwocky class. Eet's a type-o. Shoulda been 'Wockit'.
Want even more fun? Try this (say, frame 1 of a fresh movie, with a button on the timeline named, ironically enough, "button"):
-
function Button_Clicked() : Void {
-
trace( "You clicked the button." );
-
}
-
-
button.onRelease = Delegate.create( this, Button_Clicked );
Test the movie. Click the button. Nahda.
Again, why? Flash generates no compile error due to the missing Delegate class. To have this work, add "import mx.utils.Delegate" or fully qualify the call to Delegate.create.
The problem here is that MovieClips are dynamic classes, allowing for the dynamic addition and removal of methods/properties at runtime. Hence, you can't run type checks on calls, because it's entirely possible (plausible, heck - practically a given) that the method or property called will resolve properly at runtime but not at compile time. Which is, usually, a good thing - makes for RAD and fun/cool Flash-isms (translation: code that would make anything other than a Javascript/VB developer cringe, yet manages to do really neat stuff).
Solution? Don't develop on the timline. Always create an application class, instantiate it, pass the timeline to to it, and let it do it's thing.
Or don't make type-o's (which really do seem to be the bane of my existence lately).
Share me:
These icons link to social bookmarking sites where readers can share and discover new web pages.
The shouting could be heard through the hallways. Every television in the building (and there are quite a few) was tuned to a rival, but for once no mention of this was made. Hopes were high, adrenaline running to the extreme.
It seems Intel want to get into every