I’ve been doing a series of dynamic, engaging, interactive, educational and disturbingly sexy workshops on topics from the new AS3 Bible. These workshops are hosted by the fearless FlashCoders NY user group. If you’re in NYC and want to drop by, check the meeting announcements. Having a copy of the book isn’t required! (But I sure recommend it, duh!)

I give the workshops every other Wednesday, give or take. Tonight’s is on Pixel Bender! Be sure to stop by!

As an aside, you may be curious what I’m up to. Actually, you aren’t, but I’ll tell you anyway because I’m amped. I’m juggling several iOS projects on iPhone 4 and iPad, I’m days away from launching an amazing collaboration with artists/directors Radical Friend, the creators of openFrameworks, and the talented folks at The Science Project — an experimental art piece driven by Unity and oF. And what the hell, I’m trying to learn 3D modeling (again) (finally). I heard that I might be giving a series of iOS dev video training episodes… stay tuned if you want to hear more!

Turning a DisplayObject into a 3D DisplayObject is as simple as assigning a value to its rotationX, rotationY, rotationZ, or z properties. But how do you turn it back? I tried giving all these properties a value of 0, but after their animations completed they were already 0. An object at z=0 still renders in 3D, using bitmap caching. Setting these values to NaN was no better.

The solution I found is to null out the 3D transformation matrix and assign a 2D transformation matrix. This can be accomplished like so for a DisplayObject named sprite:

var matrix:Matrix = new Matrix();
matrix.translate(sprite.x, sprite.y);
matrix.rotate(sprite.rotationZ);
sprite.transform.matrix3D = null;
sprite.transform.matrix = matrix;

In this code I simply drop the transformations that are inapplicable to 2D space. This is fine when your object is already coplanar with the stage.

Anyway, quick tip if this ever had you scratching your head too.

Read the article on Photon Storm

The article shows that Flash Player is already fairly optimized for graphical composition operations when compared to blitting. Both showed similar framerates. However, the cacheAsBitmap operation caused an exponential increase in memory consumption when the number of sprites on stage increased. Ironically, the comparison was run by the creator of the Pixel Blitz library who, I’m sure, had a difficult time presenting the results.

There are some good details in the article so if you’re interested, read the whole thing before you decide if you agree.

Have you done any work with bit blitting or sprite sheet animation? Have you found it to be beneficial? Tell us your thoguhts.

I’m going to keep one as a trophy but if you can read chinese and you’d like a copy, let me know and I’ll send you a present*!

*(If you’re outside the US, i’ll ask you to pay for shipping)

Interfaces are amazing things. When I was young and green, I didn’t understand their purpose, but after working with them for a while, I will defend their use to the end. I try to create lots of interfaces early on in my projects and I find that by keeping things flexible, it saves more time despite the extra typing, pardon the double entendre.

But this is not an article about why interfaces are so great. No, this is an article about the mysterious gap in the Flash Player API with regards to an interface for DisplayObjects. If you have a class typed as something like IView, there’s no way to enure that IView can be a parameter of display list functions like addChild().

Why can’t we guarantee that something is a DisplayObject through interfaces? There is a practical answer. The inner workings of the Flash Player are slowing unfolding to us with each version. We now have low level access to sound, byte streams, and text rendering. However, the display list still relies exclusively on one of the only truly abstract classes in ActionScript 3.0, the DisplayObject. Because a low-level drawing engine is not exposed to AS3 programmers, we don’t know how it works and we cannot guarantee through an interface that an arbitrary class can be drawn.

Fortunately, there are some workarounds that can help, each with their own strengths and weaknesses. Personally, I think #2 is the way to go. It’s practically dripping with polymorphic goodness.

1. Make your interface inherit from IBitmapDrawable and IEventDispatcher

   DisplayObject is the only class that uses both of these two interfaces so by combining them in your interface, you can sort of be sure you’re working with a DisplayObject. Still, this is my least favorite solution

   Pros:

   • Uses interfaces exclusively.
   • Only a DisplayObject would implement both of these.

   Cons:

   • There’s nothing to stop you from using this to create a class that isn’t a DisplayObject and that could cause problems.
   • You would still have to type cast to DisplayObject to use this as an argument for addChild().

2. Create an interface that exposes a method to return the object as a DisplayObject

   My personal favorite solution. It not only solves the problem of guaranteeing that a class can go in the display list, it doesn’t even require that the class be a DisplayObject.

   Here’s an example of what this would look like. IDisplayObject.as

   Pros:

   • Flexible solution that conforms to good OOD principles.
   • Uses interfaces exclusively.
   • Easy to apply. You can usually implement it with a single line of code: return this;

   Cons:

   • Requires you to use asDisplayObject() every time you want to use the object as a DisplayObject.
   • Calling foo.asDisplayObject() would throw an exception if foo was null so additional checks may be necessary.

3. Use an abstract class that inherits from DisplayObject

   Not an ideal solution primarily because Flash doesn’t have true abstract classes (although there are workarounds) but still totally valid.

   Pros:

   • Guarantees that the object is a DisplayObject. No type casting required.
   • Abstract classes can be treated virtually the same as an interface for practical use.

   Cons:

   • No true abstract classes in Flash.
   • Not as flexible as an interface-based solution since it forces you to inherit from DisplayObject.

This version will not be backwards compatible, however, there’s finally some Decent Documentation!!! There’s also a new blog devoted to KS.

GO GET IT NOW!

Here’s some of the new features. You can view all of them by checking out the change log.

• Usability
  • REFACTORED all classes with usability and stability in mind.
  • UPDATED all ASDocs
  • ADDED several new methods in the TweenFactory for easy tween creation.
• Synchronizer and Time
  • REFACTORED The way time is handled throughout.
  • ADDED ISynchronizerCore and example core classes. This allows advanced users to switch between different methods of timing (e.g. enterframe or timer based)
  • ADDED FrameRateUtil for getting instantaneous and averaged framerates of the system. The FrameRateView now makes use of this class and has more options.
• Action Architecture
  • REFACTORED action classes and extracted several interfaces from them.
  • ADDED jumpToTime and jumpByTime functionality to actions.
  • ADDED Looping via a new group called KSLooper.
  • REMOVED complicated and rarely used action triggers from AbstractAction.
  • ADDED togglePause() method and progress variable to AbstractAction (for getting percentage complete of an action).
• Tweens
  • CHANGED constructors in KSTween. Emphasis is now on using TweenFactory.
  • IMPROVED Object parser in TweenFactory
• Action Groups
  • ADDED Syntactic sugar to the group constructors. using an array in the constructor for a parallel group adds a sequence and vice versa.
  • ADDED totalDuration to groups to show the duration of all child actions in a group.
  • ADDED KSRandomGroup.
  • REMOVED KSSteppedSequenceGroup because it seemed kinda useless.
• Loading Actions
  • REFACTORED Loading actions. Now they’re much easier to use and more powerful.
  • ADDED KSLoadQueue for quickly creating a class to load files from the network in a batch.
  • ADDED the resultList property to the ILoaderAction interface so that you can quickly access the loaded files in a batch.
• Misc
  • RENAMED several classes and reworked package structure
  • ADDED KSAsynchronousIteration for running processor-intensive for loops spaced out over a period of time so that they are essentially asynchronous.
  • FIXED several minor and major bugs.

But resource bundles can’t help you in every scenario. I often find myself needing to construct a sentence with live data inserted. For this, the resource strings are less helpful. For example, how would you write:

"At " + time + ", you received a message from " + userName + "."

With resource strings, you would have to do something like

at=At
message=, you received a message from
period=.

Which completely negates the whole point of using resource bundles. What to do?

Token replacement

What I really wanted was a way to inject data into the string. I’ve seen this done by use of tokens in other languages like Objective-C so I thought I’d give it a try. The result was surprisingly lightweight.

I created this utility that lets you use tokens (delimited by % signs) that can be replaced by live data when you retrieve the resource. Using this class, the example above would look more like this:

receivedMessage=At %time%, you received a message from %userName%.

// then in your code
trace(ResourceStringUtil.getResoureceStringWithTokens("receivedMessage", {time: "11:49", userName: "Mims"}));

// displays
At 11:49, you received a message from Mims.

Here’s the source code Feel free to use it and modify it for your purposes.

I’m very pleased to announce that one of my latest projects has just gone live. The Deepening – Select Your Own Adventure Edition has just gone up on Atom Films. Go give it a look, it’s hilarious.

The video is a Good Cop / Bad Cop action show where you get to choose what happens next. It was created by the brilliant Duncan Brothers who asked me to help build the Flash portion of it. Enjoy!

deepening.atom.com

Runtime Environment

SWF Files
Swf files are compressed, multipurpose packages designed to contain the following data: raster and vector graphics, video, audio, text, fonts, animation, and actionscript code. Swfs can be loaded at runtime whenever necessary and can use both static and dynamic linking based upon the compiler settings. The runtime environment uses security sandboxes for loaded swf files. The security settings primarily limit the extent of filesystem access and cross-domain access that swf files can use. Adobe has provided the swf file format spec and has recently provided the FLV video format spec and has declared that they will provide the RTMP spec as well.

Flash Player & AVM2
The Flash Player runtime is a very light-weight, virtual machine and handles system calls. The Flash Player includes both AVM1 (AS1, AS2, for Flash versions 1-8) and AVM2 (AS3 for Flash 9,10+) which processes compiled Adobe Bytecode (ABC). The term AVM stands for “ActionScript Virtual Machine”*. The Flash Player uses a Deferred Reference Counting (DRC) mechanism combined with a conservative mark/sweep garbage collector. The Adobe VM uses both JIT compiling and code interpretation and may benefit from compile-time bytecode optimizations based upon compiler input parameters. AS3 computational performance is generally closer to Java than Javascript [source]. The player also maintains a variable framerate that reflects the time consumed for each frame update [source]. Each frame update consists of multiple stages that include internal player processing, rendering, and author script processing. The program framerate is the principle metric reflecting application performance.

Development Environment

Actionscript API
The Actionscript API is divided up amongst the Adobe AIR environment, the Flex environment, and the Flash environment and the Flash Player. The source for all the packages are divided up amongst swc files. Swc files are pre-compiled catalogs of classes and assets. They are similar to swf files but they are used for compile-time dependency resolution. Furthermore, the native swc’s predominantly contain code and not visual assets. An overview of the Actionscript packages is kept up to date in the Adobe Live Docs.

The Flash IDE
The Flash IDE was designed for designers, artists and animators. So, it is equiped with a layer system which reflects the stage display list and a hierarchical timeline which reflects the temporal nature of the runtime. The objects placed on the stage are represented by the timeline and can be “tweened” (using runtime interpolated 2D geometric transformations or custom shape morphs). The same timeline is also used for object creation and destruction. All stage instances are confined to a small set of native data types including: MovieClips, Sprites, Shapes, TextFields, Videos, and Bitmaps. The IDE also has a library that contains source objects for all stage instances and even instances that aren’t used on the stage. Flash projects often have several build targets (compiled swf files) that use parts of the project codebase. After Macromedia was purchased by Adobe, the Flash authoring environment has been updated to provide much better interoperability with the Adobe Creative Suite.

Adobe Flex Builder
Flex Builder is an Eclipse-based Actionscript IDE for writing and compiling swf files. Flex Builder is primarily designed to build “Flex” projects which can be written in an interface tagging language known as MXML. MXML is a declarative XML langauge used to define interface elements in a project. MXML files provide the “view” in the MVC software design pattern. Flex Builder also provides plenty of useful features like code completion, syntax formatting, active debugging, memory profiling, and project building that expose errors and warnings during development time. Because the Flex framework is not bundled with the Flash Player, Flex projects must statically link to all swc assets specific to Flex which amounts to greater than 500kb. This is very unnatractive for most users, thus Adobe has provided means by which the download can be significantly decreased. Flex Builder is also used to deploy applications for the Adobe AIR platform. Adobe AIR is a desktop runtime that combines webkit with the AVM2 portion of the Flash Player. AIR can be likened to a closed source Java SE runtime but provides a smaller learning curve and greater accessibility than what comes with the Java ecosystem.

Compiler
Since Adobe has launched the Flex platform they have provided free access to their Flex and Actionscript compiler and SDK. They have also provided open source projects under the Mozilla public license. The compiler (mxmlc) provides an impressive amount of flexibility and customization for swf compiling. It can be configured with command line options or a configuration XML file.

* correction 09-12-2009, I had previously stated that the term AVM meant “Adobe Virtual Machine”, this is a mixup. It actually means “ActionScript Virtual Machine”. Thanks dbam.


getNumberAsHexString(255); // 0xFF
getNumberAsHexString(0xABCDEF); // 0xABCDEF
getNumberAsHexString(0x00FFCC); // 0xFFCC
getNumberAsHexString(0x00FFCC, 6); // 0x00FFCC - Uses 6 as a minimum number of hexits

I’ve added the code to the AS3lib as  as a global function. I may move it to a utility class later on. You can view the source on Google Code.

Incidentally, in a moment of bug-fixing frustration, I found this article on O.C.A.S. which describes how the same functionality is already built into the toString() method! However, the work isn’t completely wasted since my version includes the option to show leading zeroes and adds “0x” at the front of the result.

I’m doing a little exercise in a book that makes a textfield in which each letter can only be entered once. Not very useful, more of a teaching thing really. However there’s a bit of code that says:

var tf:TextField = event.target as TextField;

I don’t understand this at all! What the hell is event.target as TextField? Anyway here’s the full code for context’s sake:

package com.FoundationAS3.ch6 {

	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFieldType;
	import flash.events.TextEvent;

	public class PreventDefaultTest extends Sprite {

		public function PreventDefaultTest() {
			var tf:TextField = new TextField();
			addChild(tf);

			tf.width = stage.stageWidth;
			tf.height = stage.stageHeight;
			tf.type = TextFieldType.INPUT;
			tf.wordWrap = true;

			tf.addEventListener(TextEvent.TEXT_INPUT, onTextFieldTextInput);
		}

		private function onTextFieldTextInput(event:TextEvent):void {
			var tf:TextField = event.target as TextField;
			if (tf.text.indexOf(event.text) > -1) {
				event.preventDefault();
			}
		}
	}
}

Thanks,
-Neal

My response after the jump.

Neal,

First of all, let me say that preventing the default event handler, e.g. for a TextField, is rarely used and isn’t worth spending a lot of time discussing.

On the other hand, the as operator (along with the is operator and the type cast) are totally useful and you should learn all about them. First, let me cover is:

is

is is an operator that evaluates whether some object is of a certain type. The syntax is [object] is [type]. The term ‘type’ is similar but not interchangeable with ‘class’. A type can refer to not only the class of an object, but also the super-classes it extends and interfaces it implements. An example:

var sprite:Sprite = new Sprite();
trace(sprite is Sprite); // true, because the sprite object is an instance of Sprite
trace(sprite is DisplayObject); // true, Sprite is a subclass of DisplayObject
trace(sprite is MovieClip); // false, MovieClip is a subclass of Sprite.
trace(sprite is IEventDispatcher); // true, DisplayObject extends EventDispatcher which implements IEventDispatcher.

Note that sprite is not a MovieClip but a MovieClip is a Sprite. Because MovieClip extends Sprite and contains all the same methods and properties as Sprite but not the other way around.

Note: the instanceof operator commonly used in AS1/2 still exists in AS3 but is for all practical purposes deprecated by is (although still useful if you’re manipulating prototypes). typeof is also related but shouldn’t be used in place of is because it only returns strings for primitive data types like Object and String. In order to get the actual name of the class that an object is an instance of, you can use the flash.utils.getQualifiedClassName() global function.

as

as functions similarly to is except that it actually will attempt to coerce the object into the data type that you ask for. Coercion, AKA type conversion or casting, is the act of changing the data type of an object.

With the case from your book, an Event object has a target property which refers back to the object that originally dispatched the event. Since the Event object is designed to be sent out from all different types of objects, the target’s data type is Object (the mother of all the other classes). So, if the variable you’re defining is a TextField, you’re expecting an object with a text property. Object, doesn’t have a text property so you have a dilemma. The solution is to cast the object into the type you want it to be, basically forcing it to be more specific.

var textField:TextField = event.target; // Throws compile error because target is an Object not a TextField

var textField:TextField = event.target as TextField; // OK! as long as the event target actually is a text field

Going from a more generic type to a more specific type is called a downcast. Going from a more specific type to a more generic type is called an upcast. Upcasting in ActionScript, as with most other languages, is done automatically and is always safe. e.g. a Sprite can be used as a parameter for a function that requires a DisplayObject. Downcasting on the other hand is unsafe meaning that you can’t always guarantee that it will work. A DisplayObject is not necessarily a Sprite.

When an attempt to downcast with as fails, the value returned will be null:

var string:String = new String();
var textField:TextField = string as TextField // string can't be converted. textField will be set to null

If you’re not sure whether your object is the right type (and you should never assume it is) check to see if the value is null before proceeding:

var typedObject:TypedObject = mysteryObject as TypedObject;
if (typedObject != null) {
	// conversion was successful! do something with typedObject
} else {
	// conversion failed
}

Type casts

Another way to do this with slightly different results is by type casting. Type casting works with the syntax Type(object) and is functionally similar to object as Type. The only difference is with a type cast, you get a runtime error if the coercion fails.

var textField:TextField = TextField(event.target); // if event.target is a TextField, you're good. If not, you get an error.


you can also shortcut like this:

TextField(event.target).text = "foo";

Conclusion

Why are objects like event.target given such generic data types? The idea is that you want to minimize the requirements of a property, parameter, or function to maximize the number of objects that will qualify thus making your program more flexible. In other words, strive to use the most broadly defined data types that you can get away with.

For example, say you’re creating a simulator program for getting a person from their home to their job. You may be tempted to define your modeOfTransportation variable with a type of Car. But down the road the company you’re working for wants to create a more green image for themselves and suggests using alternative modes of transportation. If you’re code is based on Car, it’s limited in what you can do with it. However, if you had used a Vehicle type (includes Car, Bike, Motorcycle, Donkey) instead, you may not have had a problem. Using interfaces like IConveyance makes your program even more flexible because you can include non-vehicluar objects like MolecularTransporter, Feet, and CrowdSurfing as long as they satisfy the interface. In fact, I would suggest as an experiment that the next time you start a project, try coding all the interfaces first before you move on to coding specific classes. You’ll be surprised at how flexible it is and how it forces you to consider the roles of your classes from a higher level.

Though you should strive for generic types, sometimes you will need to get specific. If your program has a gas station simulator in it, the fillTankOfVehicle() method might require a MotorVehicle class (includes Car, Motorcycle, Plane) instead of simply Vehicle. Still, you should only get very specific when your program requires it. If you are making a racing program, use F1RaceCar only when a simple Car won’t cut it.

I hope this helps! This is definitely a difficult topic even for experienced programmers to grasp!

Before I begin, I must stress to you, if there is any way you can avoid downgrading your code, you should avoid it! If it’s a matter of making two systems communicate, there are countless reasons that it would be better to upgrade your code from AS2 to AS3. There are even ways to host your AS2 code in an AS3 wrapper. In my case, an important requirement (that the deliverable absolutely must be AS2) was left out of the original scope of work due to a misunderstanding but anything that doesn’t cause project stoppage should be considered carefully.

I must also preface this article by reminding the reader that there is no 1-to-1 conversion from AS3 to AS2 (nor the other way around). There are loads of features added to Flash Player 9 that simply don’t exist in Player 8. Some things you’ll be able to convert with a simple find and replace. Some things you’ll need to re-create in AS2 or re-think completely. Some things you just won’t be able to do. This article only covers the stuff I ran across while converting my files and is by no means comprehensive. However, I hope it gives you a good starting point to work from.

Converting the document class

Since you’re a smart, cool AS3 programmer with a good sense of humour, I know you use a document class in your FLA files or a main application class for your FlexBuilder project. Right? Good. Of course, AS2 does not support document classes and all code must be run from the timeline. You have a couple of options here. You could move your document class to the timeline and remove the class specific portions of the code. Perhaps a quicker and easier solution is to modify your document class to take a reference to the root. So you have something like this on the first frame…

var documentClass:MyDocumentClass = new MyDocumentClass(this);

Just keep in mind that your document class will need to store a reference to the root that’s passed in as well as make references to things that were on the stage. For example…

public function MyDocumentClass(mc:MovieClip) {
   this._mc = mc;
   this.thingOnStage = _mc.thingOnStage;
}

Cleaning up syntax errors

The first step to take once you can compile your code is to run it and fix each compile time error one at a time. To save you the trouble of some of the more common ones I found, I created this list of common syntax problems.

Search and replace:

• void -> Void
• int and uint -> Number
• DisplayObject, DisplayObjectContainer, Sprite -> MovieClip
• public class -> class
• internal -> public
• protected -> private
• override -> (nothing)
• mouseEnabled -> enabled
• [obj] as [type] -> [type]([obj])
• [obj] is [type] -> [obj] instanceof [type]
• const -> var (or optionally, to implicit getter)
• Add underscores before MovieClip variables. e.g.: x, scaleY, alpha -> _x, _yscale, _alpha including:
  • alpha -> _alpha
  • x,y -> _x, _y
  • scaleX,Y -> _xscale, _yscale
  • mouseX,Y -> _xmouse, _ymouse
  • visible -> _visible
  • currentFrame -> _currentFrame
  • totalFrames -> _totalframes

Add:

• import statements for classes within the same package (not required in AS3)

Remove:

• import statements for AS3 packages (e.g. flash.display.* )

Convert:

• _xscale, _yscale, _alpha – Convert from decimal to integer (0.2 becomes 20).
• Convert Timer to setInterval
• Convert Loader to MovieClipLoader
• Remove package declaration but copy the package name and put it before the class name. Also remove closing } from the end of the file.
  e.g. :

  package com.mysite.package {
  	public class Foo {
  	 	//...
  	}
  }

  becomes

  class com.mysite.package.Foo {
  
  	//...
  
  }

Other tips

Events are a huge part of AS3 development and Player 9 supports a fully event-driven development style. Unfortunately, AS2 is heavily lacking in this department and while events can be recreated in AS2, it lacks method closures and bubbling that make AS3 so nice. To downgrade, I did two things. First, I recreated the event dispatcher in as2 and second, I made heavy use of event callbacks and the Delegate class.

com.mimswright.events

In order to change as little of the event code as possible, I looked back to previous AS2 projects where I had used Danny Patterson‘s EventBroadcaster classes. These classes worked roughly the same as the EventDispatcher class in AS3. I took the liberty of brushing up the code and making it look as much like the AS3 EventDispatcher as I could. I’m making it freely available for use.

as2eventdispatcher

event callbacks

Most of the events you’ll probably be using must be triggered by callbacks in AS2. That is, you define a function that gets called when an event takes place like

onMouseMove = function ():Void {
   //do something
}

Keep in mind that in AS2 there are no method closures as there are in AS3. That is, a function isn’t necessarily executed in the scope that it exists in. In even simpler terms, a function doesn’t know what object it’s associated with. Because of this, code such as button.onRelease = object.handleClick; executes the handleClick function from the button context and my not work properly. Fortunately, AS2 code can make use of the mx.utils.Delegate class – specifically, the Delegate.create() method. This artificially maintains the context in which the function was supposed to be called. So your code should look like button.onRelease = mx.utils.Delegate.create(object, object.handleClick);

I hope this has been a helpful start for you poor souls who are faced with the challenge of down-converting code. Good luck to you and feel free to add your experiences to the comments.

This could be very useful for code optimization and for a general understanding of what’s going on behind the scenes.

Perhaps the most striking comparisons in this tool are the ones that compare Vectors to Arrays. Looping Vectors appears to be about 60x faster than looping through Arrays. Someone recently asked me when you would want to use Vectors and my response was whenever you possibly can. And if you think about it, the times which you need an untyped Array are (should be) almost never.

This version check is very simple. It checks a version number in the client code against a version number of the library (or external classes) when the main class of the library is initialized. It is also completely optional (so average users don’t need to mark up their code with version numbers).

Here’s an example:

Say you normally initialize your library using:

MyLibrary.initialize();

Which calls the initialize method:

public static function initialize():void {
   // initialize library here
}

If the external code changes unexpectedly (say through an SVN update) this could cause problems that are difficult to trace. The solution is to modify the initializer to match the client code version with the initializer version.

public static const VERSION:String = "1.6";
public static function initialize(versionCheck:String = VERSION):void {
   if (versionCheck != VERSION) {
       throw new Error ("The version check failed! This library is version " + VERSION + ". Update your code or GTFO!");
   }
   // initialize library here
}

And when you run the initializer, use the version number you’re expecting.

MyLibrary.initialize("1.6");

Some things to notice with this approach:

• I used a string instead of a number for the version number so that it would allow for sub-sub version numbers and other markers, e.g. “1.6.24 beta r545″
• Because there is a default value for versionCheck in the initializer, providing a version number is optional. Using MyLibrary.initialize() will still work and throw no errors.
• Unfortunately, there is not much you can do if the version numbers don’t match except to warn the client that the external code has changed. Still, I’ve found this to be very useful.

The code for my initializer in its entirety after the jump…

From KitchenSync.as

/**
* The current version of the library. Use this to verify that the library is the
* version that your software expects.
*/
public static const VERSION:String = "1.6";

/**
* Flag noting whether the engine has been initialized.
*/
private static var _initialized:Boolean = false;

/**
* Initializes the timing core for KitchenSync. Must be called before using any actions.
*
* @param frameRateSeed must be a DisplayObject that is added to the display list.
* @param versionCheck a string for the version you think you're using. e.g. 1.2 This is recommended
*                                         but not required. It will throw an error if you're using the wrong version of KS.
*/
public static function initialize(frameRateSeed:DisplayObject, versionCheck:String = VERSION):void
{       

	if (_initialized) {
		throw new IllegalOperationError("KitchenSync has already been initialized.");
	}
	if (versionCheck != VERSION) {
		throw new Error ("Version check failed. Please update to the correct version or to continue using this version (at your own risk) put the initialize() method inside a try{} block.");
	}

	// Initialization code omitted

	_initialized = true;
}