Monthly Archive for February, 2009

The much dreaded Singleton

I have come across so much contempt towards the Singleton, it’s almost scary. Singletons are crucified all over the place, and whilst there are very sound theoretical reasons to avoid abusing the pattern, the Singleton has a healthy place in ui programming.

More often than not development for Flash puts us against unique instances of things. Usually, this happens in the context of UI programming: a single stage, a single mouse, etc. Some aspects of many applications are also better off built centralised, for sometimes one simply wants to avoid two objects performing clashing updates on something (a good example is animation of gui components and overwriting of property interpolation tasks in tweening engines). In such situations, one who blindly aims to avoid building a Singleton most probably ends up isolating the shared state needed to sync the instances in static vars and methods, achieving (in the best case) something that looks more or less like a Borg design. New catchy notions, same old enemy – global state.


This has nothing to do with loose coupling or design patterns, but a Singleton is usually a better alternative to static vars and methods for at least one big reason. Static stuff in Actionscript is very slow to access. (What was it, 10 times slower?) A call to a method on a singleton will make use of one static var lookup – the reference to the singleton – and that only if a reference to the object is not already locally available. The same method, if declared static, will probably have to access at least one more static variable in order to read and write global stuff. [EDIT: This is not entirely correct, see the follow-up benchmark on static access performance.]

It seems that in Python sharing state among instances is considered more elegant than using Singletons. One could easily extend the same logic to Actionscript: more transparent code, good-looking instantiation with new, etc. Still, if more than one static var is to be accessed during method execution on such objects, or if the objects are to be created and discarded on a usual basis, performance-wise, Singletons will most likely be a faster alternative.

In this context, let me demonstrate my personal approach to implementing a Singleton:

public class Singleton
	public static const instance : Singleton = new Singleton ();
	public static function Singleton ()
		if ( instance ) throw new Error ( "Already instantiated." );

My trick looks like an exploit and a generally terrible idea (now how could a constant change its value?), but works perfectly fine AND avoids the need for the additional overhead from a getInstace () method call and from accessing a private static var to return the instance.

At least some loose coupling please

Static vars and methods, shared state among instances, and Singletons are almost equally deadly to loose coupling. In all of those cases, typing and access issues hinder substitution of the class in question in code variations or upgrades.

The above is completely true, unless one decides to take the Singleton pattern a bit beyond what it usually looks like and to add a layer of abstraction:

public class AbstractSingleton
	private static var instance : AbstractSingleton;
	public static function getInstance () : AbstractSingleton
		if ( !instance ) throw new Error ( "Not instantiated." );
		return instance;
	public function AbstractSingleton ()
		if ( instance ) throw new Error ( "Already instantiated." );
		instance = this;
	public function abstractMethod ( ... ) : *
		//	to be overriden.

If used as intended this should do the trick. One could probably do a few things to strengthen the implementation, preventing instantiation of the abstract class, even adding some sort of auto-instantiation try-catch trick for the child classes, and so on and so forth. What’s important however is that this ‘abstract’ Singleton pseudo-pattern provides freedom in chosing which concrete object to instantiate at app start, and that’s already quite a gain in terms of loose-coupling.

Singletons can be rather healthy in a UI context

Again, Singletons are a good thing in the context of gui programming. All voluminous and immutable objects are healthy candidates for becoming part of the global state; a provider for a huge and static bitmap is a great example, also an audio mixer for button noises and ambient loops illustrates the point, for there is an absolute benefit of keeping those globally accessible and limit them to a single instance – there is a guarantee that the underlying bulky resource will be loaded only once in the memory.

Also, when an application relies heavily on client/server interactions, and when these put ui-responsiveness at stake, a globally accessible remoting service, be it static, Singleton or Borg, will enable the programme to centrally cache repetitive interactions’ results.

An edit to my boring conclusion

Instead of my previous empty conclusion, I’ll post someday an example of how one could actually get unmatchable loose coupling with the help of a Singleton registry for services.

Bookmark and Share

Vector.unshift () bug

I find it weird that there has been no big noise about this one already. After wasting enough time on debugging, I figured it was time to google JIRA:

In brief, Vector unshift () removes elements from the end of the vector while adding what’s to be added at the beggining.

A bug like this makes me so sad. Maybe because the typed array was such an anticipated feature of FP10, and because this is such a simple, stupid and brutally overlooked bug. I was thinking, the problem is listed as a compiler bug; I’d rather blame it on the Player API. Any opinions?

Anyway, the workaround is as simple as it gets, but is just as ugly:

vectorInstance.splice ( 0, 0, ... );

And you might as well vote for it on JIRA.

Bookmark and Share

Hello world!

Hello there. Over time I got convinced that keeping it all private is so not fun. And now that my modest time-endowment has limited my ability to get stuff out of my brain and onto the net, I was struck by the revelation that sharing my ideas might as well result in someone else doing the hard work for me. So here I am, starting a blog, and you are most welcome to share stuff back.

Well, hello world! As you might have guessed by now, this blog will be about flash and flash-related stuff. Every now and then I will be outputing some thoughts, code and filler in a hope to maybe be of some use and/or inspiration to the other flashers around the place. Also, I have a couple of cool projects that have been shaping up for a while now, and if I do manage to make them reasonably presentable, all will go on googlecode.

These are the good news, now lets begin with the bad.

Bookmark and Share