Fleecie,
>>not that I have anything against singletons, but I know a few people who just won't touch them.
And I hear the Amish don't use telephones.
Seriously, it is an in interesting idea that's been batted around a bit here. I appreciate the effort, on both of your parts to explore the idea. The problem of running multiple Cores (for Flex Modules or Flash based apps or a mix), is a big one and now it has been explored from all angles.
One approach was to register and unregister all the commands, Mediators and Proxies for a Module when its loaded. It involved a lot of coordination to keep track of what to load when and still had namespace issues. That is notification constants in two different apps could interfere with each other since they were registered into the same Core.
Then there's the Singleton approach that says, the problem with running multiple cores is that the singletons keep you from creating more than one blasted instance! What a pain. If they were like regular classes there'd be no problem... That is except that in any but the most trivial parent-child case, you will end up writing special actors to manage the separate cores.
There is a reason for the use of Singletons in PureMVC as there is for every pattern in the framework. The reason, as described in the Gang of Four book, is to absolutely insure that an actor cannot be instantiated more than once.
The classic retort to this is
just don't instantiate more than once, but it is often the case that that best practices, or sometimes even common sense isn't followed by 'other' developers. This can be due to lack of time, discipline, familiarity with the tools at hand, or any number of pressures.
For instance, I came across this developer's sad lament:
http://board.flashkit.com/board/showthread.php?t=760317 Dropped into a project late, the guy finds himself in an app where apparently all the rules have been broken. He's trying to figure out not only the best way to use the framework but also how to untie this other person's knot at the same time.
So imagine this is not code for 'Yet Another Flikr Gallery - Beta' but, oh, lets say a
pacemaker. And the existing app you're supposed to figure out has this nasty problem of sometimes instantiating more than one clock, causing the patient to dance like a chicken briefly before collapsing of heart failure. But it only happens every now and then.
The point is there are times when you want your software to create only one instance of something no matter what and that's when you reach for the Singleton pattern.
However, we do want multiple MVC Cores to be able to reside peacefully and interact. To communicate with each other even, without namespace collision or extra overhead to manage the separate Cores.
And to this end a new version of PureMVC - 'MultiCore', has been created using Multitons rather than Singletons for the Core actors. The difference is that rather than holding a single instance, each actor holds a hash of instances, each with a name, in the same way that Mediators and Proxies are cached.
This achieves the same end, but still ensures that your app cannot instantiate a given Core more than once. It works with Flex Modules and but will work with Flash movies as well. The management of all the instances is handled by the actors themselves as it always has been, you merely pass a unique key to the getInstance method.
The really nice thing about it is that all the same assumptions about the framework actors remain true, known best practices still apply and you now have implicit support for Modular development.
-=Cliff>
