Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: How to make notify system singleton less?  (Read 12468 times)
theFlashWizard
Jr. Member
**
Posts: 13


View Profile Email
« on: February 08, 2008, 04:54:10 »

Hi guys,
I'm trying to extend the framework so that you can choose to not use singletons.
http://forums.puremvc.org/index.php?topic=235.0

Changing the concrete Facade, Model, View and Controller is no problem, but the Notifying system worries me.
Because a lot of classes (MacroCommand, SimpleCommand, Mediator and Proxy) extend the Notifier class. It's impossible to change it without having to create copies of his subclasses.

I'm thinking about the following options:
- Copy Notifier, make facade changeable (By param in constructor of public property), copy all it's subclass to extend it.
- Copy all subclasses of Notifier and change the facade (less clear I guess)
- Change all the pureMVC classes so that you can give almost every class a reference to the facade. (But this is useless for the normal pureMVC)
- Make this into a alternative version of PureMVC
  (Unless one less someone has a better idea this seems the best option, pureMVC just doesn't seem flexible enough)

(I can't make a facade singleton for every sub MVC because this Notifier can only be hooked to one facade. Than we would still need to copy the whole framework for every sub MVC. )

A possible way to make the notifying system in pureMVC more flexible is to use compilation instead of extension to add Notifying capabilities. (Like you can use a custom subclass of EventDispatcher in as3.0)
This way I could extend the notifiers (MacroCommand, SimpleCommand, Mediator and Proxy) and change there notifier via there protected notifier property.
This seems okay, but this involves changing the whole framework, in my opion it's better to change it to a singleton less framework right away.

Do you guys have any ideas?

Many thanks,
Peter
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: February 08, 2008, 05:51:36 »

The framework managed here will not be refactored to be singletonless. It works just fine as is. The offer for repo space for a utility and demo stands however.

Also,I'm not sure what you mean by having to copy all framework files for every 'subMVC' how is that?

-=Cliff>
Logged
theFlashWizard
Jr. Member
**
Posts: 13


View Profile Email
« Reply #2 on: February 08, 2008, 01:18:26 »

The notifier has a direct/fixed reference with a facade singleton. Since it can only have one link you would have to copy the notifier to link it to a other facade. You then understand that you also need to copy all his subclasses. etc etc.

But could you think of another solution than?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: February 09, 2008, 07:17:59 »

No, not offhand.

I'm not surprised that its not easy to do. The Facade singleton is a core part of the nature of this framework.

If I were going to replace all the classes to support this subMVC idea, I believe I'd implement the core actors as multitons.

-=Cliff>
Logged
theFlashWizard
Jr. Member
**
Posts: 13


View Profile Email
« Reply #4 on: February 09, 2008, 09:15:50 »

Okay... but can we start a discussion about that than?
Because I don't think that's the right solution. Just like I explained here:
http://forums.puremvc.org/index.php?topic=235.0#msg907

My biggest question is, what is the advantage over a singleton less version?

Correct me if I'm wrong but if you make it multiton you still have to pass a reference to parts like the notifier subclasses. Which is the same problem I have with a singleton less version.

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: February 09, 2008, 11:33:59 »

I read the 'Singleton pattern considered stupid' blog post you linked to, and it's a fair and apt summation of the downsides to Singletons. I certainly agree that writing an application with lots of custom built Singletons is not a best practice.

Leveraging the Facade, which hides the entire MVC apparatus behind a single API, so that you may use other simple patterns and keep your code loosely coupled is hardly the same thing.

But this discussion isn't really going to help us much. It doesn't look like writing this as a utility makes sense, and the change too core to the way the framework is designed to just make overnight.

The current framework is reportedly quite serviceable, and the ramifications of the changes you're talking about are not yet clear.

Meanwhile further enhancements and bug fixes are being held up for release as there is a huge pile of work that grows higher daily that is needed to new contributors, demos, utilities and ports ready for prime time so that the release can happen all at once.

Being the person responsible for the framework (who spends hours every day seriously considering and answering questions like this very one), I'm not just not prepared to make the surgery to the officially offered version framework at this time.

It may be that this is something that belongs at a much later milestone, when we can comfortably support branches of the framework to consider such possibilities.

In the meantime, if you want to completely rewrite the framework without Singletons you are completely free to do so. I don't want to disuade you. If you do rebuild it, and come up with demos and docs and best practices, I'd still be glad to look at it all and see how to fit it into the new scheme of things.

But you just don't know till you get there, and it's pretty far off the current path.

-=Cliff>
Logged
theFlashWizard
Jr. Member
**
Posts: 13


View Profile Email
« Reply #6 on: February 10, 2008, 10:42:07 »

Okay, I understand and respect your priorities.
I will try to go ahead with my plan and build it. This will give us more insight and than, when the time comes we can possible integrate it in the main PureMVC version.

Is there a possibility to make this version as sort of a port? So that it is always open for the public? Or do you prefer seeing it being build first?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: February 10, 2008, 02:37:22 »

Thanks for understanding about the priorities.

I think I'd rather see it in action, to understand what the best way to handle it is. It needs demos and unit tests and most of all, best practices for use.

Right now there's already one huge problem with making it a port: documentation.

I'm in the process of migrating demos and utilities to PureMVC 2.0, as well as the documentation. It has examples in the 'reference implementation' AS3. But it must stand as the primary doc for all the other ports.

Those ports then have to describe everything that varies from the reference, both in practices as well as syntax. We want them to adhere closely enough in practice so the main difference is syntax.

That's a tough enough job. But the practices for a singletonless PureMVC make it a totally different beast. At least I believe it does. We'll see when you're done with it and have some non-trivial demos going.

-=Cliff>
Logged
Pages: [1]
Print