PureMVC without singleton's?

[theFlashWizard]

I'm thinking about making a singleton less pureMVC version. This because I want to be able to make sub PureMVC's.
We where building a very large game. This game had several mini-games and a pda that all had a lot of there own logic.
Because we wanted to be able to test games separately, didn't want every game to always exist and didn't want to have to risk to have non-unique names we created sub PureMVC's.
But, because PureMVC is build with several singletons we needed to copy most of the PureMVC classes to every sub PureMVC.
Another problem with singletons is that they don't get removed, so they always remember data. This forced us to build in our own destroy methods in the framework.
We felt like the only reason for all these problem's was that it is based on singletons.
We think that if you pass out all the members the correct references the framework should work as well.

Benefits
- SubPureMVC's without framework copies.
- More separation options.
- Les change off name conflicts.
- Easier unit testing.

Downsides
- Little risk on multiple instances of application facade, view, controller and model.

What are you guys thoughts about this?

[diegovolpe]

Take a look at this post:
http://forums.puremvc.org/index.php?topic=199.0

We had the same problem working with modules in Flex.

[puremvc]

Luke Bayes of PatternPark actually proposed this idea some time back but didn't have the time to put into supporting /testing, etc. And I didn't have time to fork and maintain a separate branch to see if the idea panned out.

I do understand the issues with the Singletons from a modularity viewpoint. I wonder if the answer isn't to make them Multitons (http://en.wikipedia.org/wiki/Multiton).

-=Cliff>

[theFlashWizard]

diegovolpe,
The solution seems strange and it seems specially made for this module loading function in flex. Making a sub mvc just seems a lot more natural.

Cliff,
You mean the following idea?
http://forums.puremvc.org/index.php?topic=229
Only the first posts are about what I mean, but he ruined the whole discussion with this idea to put the facade, view, model and controller in one class.
So I wanted to make a fresh topic about this.

No, Multitons are not a good solution. Most submvc's only exist temporarily and a singleton/multiton that always exist is therefor not a good choice.
There articles on this topic are very interesting:
http://www.ibm.com/developerworks/webservices/library/co-single.html
http://steve.yegge.googlepages.com/singleton-considered-stupid

The main 2 reasons for posting this idea are:
- Checking if someone didn't already made it.
- Checking if I'm not missing a big disadvantage of problem

If nobody made it already and nobody sees a problem in the idea I want to develop it anyway.
I've already made notes in the framework to check what I actually need to change.
And with these unit test you created I should be able to test it very easily.

I think it's great that you're putting so mush time into this. It doesn't happen very often that you can discus there kind of ideas with the original creator.

[diegovolpe]

It was made specially for modules because there is a high dependency on singletons and we can't change the framework source.
If there were no singletons, we could use the applicationFacade, Mediator, proxys...etc... without any changes, and it would work in Flex and Flash. Because we can't change the source, the only solution (and I agree that's strange) was changing constant names for modules.
tks

[puremvc]

The core framework does not have to be modified to support this concept.

I believe that unless there are unforseen consequences, that
there should be absolutely no problem with  implementing a utility package that implements its own Model,View,Controller, and Facade. As long as they implement the core interfaces you are free to replace some or all of the core classes as you will. The kee is doing it in a reusable way. As a utility it can be used whenever someone chooses as opposed to changing the core.

So here is your challange oh FlashWizard. Create a utility as described above and a demo that uses it. See the welcome post in the Contributor Central board for some ideas about packaging. I suggest org.puremvc.as3.utilities.nosingletons.* for the utility.

Email me and we'll talk about the utility and repository access.

-=Cliff>

[theFlashWizard]

Challenge accepted

But may I suggest you think about the possibility to use non singletons as core.
Because, well, I don't see why not. (except for all the documentation and ports that would need to be changed)

I'll send a mail later today.

[omnichaos]

I wonder what the status is of this project?
Has it been abandoned in favor of the multicore version?

Just checking 

[puremvc]

Yes and no.

We were origninally looking into a utility that would basically override the main actors with singltonless versions. That didn't pan out and it became apparent that the only way to solve the problem that the singletons pose to dealing with modules was a new version entirely.

However, I didn't feel that singletonless was the way to go since it was such a departure from the standard framework. The accumulated knowledge and docs that exist could not be expected to hold true, and would have to be rewritten and new best practices (and pitfalls) learned.

Instead opted to build a multiton based version which is MultiCore. The differences are slight, migration is easy.
 
-=Cliff>

[justsee]

Has anyone looked at Luke Bayes' approach to this for Flex?: http://code.google.com/p/flexmvcs/

----
This build differs from PureMVC in the following ways:

    * Removed unnecessary use of Singletons.
    * Added IService as a first-class participant and member of IFacade.
    * Created asynchronous commands that trigger events when complete.
    * Added composite command that facilitates synchronous and asynchronous command chaining with support for arbitrary composition depth.
    * Added MXML Facade definitions. Application Facades can be defined using MXML instead of only ActionScript.
    * Added support for Modular Flex applications, including composite Facades for each loaded module.
    * PureMVC is trying to be more than we need, we need clean, intuitive support for Flex and ActionScript. Not ECMA, Java or other languages.