Merging versions together?

[jowie]

Hi there,

This may have been asked before, but is it possible that Single and MultiCore versions will be merged together soon? Considering MultiCore is simply an extended version of SingleCore, it would make sense...

My main gripe with there being two separate versions is that we are starting to create a nice library of reusable proxies, mediators etc. Having two versions means that sometimes when we import a reusable proxy or mediator, it doesn't work because it is linked to multicore when the project is single core, or vice versa.

Wouldn't it be worth merging them like this:

:

var facade:IFacade = SingeCoreFacade.getInstance();

:

var facade:IFacade = MultiCoreFacade.getInstance("coreName");
So if a string isn't passed, it just uses MultiCore to generate a single facade named "single" or something, but to the programmer they are completely unaware of its MultiCore nature...

...or am I oversimplifying the problem?

thanks!

:-Joe

[puremvc]

Hi Joe,

PureMVC began with the idea of fully scoping the framework, building, bug fixing and then hands-off once stable. Extension by utility only. I didn't want people to have to endure the constant upgrade train that you do with continually 'improved' software.

MultiCore was the unexpected 'feature' that came out of the blue. Rather than monkey with the already near-stable Standard version, a MultiCore reference implementation was made. Those who didn't need or want MultiCore wouldn't be forced to accept it and all the issues it might introduce, or ride the MultiCore train to stability when they never even bought a ticket.

So MultiCore stabilized quickly and the question of whether to drop the standard version or merge the two was considered.

Merging is no good because every time you refer to a framework class you have to tell flex builder which one you want. Dropping the standard version also isn't kind because it forces everyone to migrate their Standard version apps. And MultiCore just doesn't make much sense in some platforms like PHP or CF. So the Multiton implementation would seem stupid and annoying on such a platform. And, all the utilities haven't been converted to MultiCore yet.

So the Standard Version must remain, though for AS3 development I recommend MultiCore for new development since its easier to test.

-=Cliff>

[jowie]

Hi Cliff,

Thanks for the in-depth reply, I completely appreciate the position. I am trying to make any project, multi or single core, using MultiCore from now on just so that all the utilities created are completely portable. The only thing I'd say is that from where I'm standing I believe that MultiCore could be plugged in underneath the single core version and people using it for single core would never even know... But that's just from where I'm standing, so that's all I'll say about it.

My problem arose when I took useful reusable proxies and mediators out from a MultiCore project and tried to use them in a basic single core project. It was only the imports I needed to change, everything else was the same, so I just felt it would be nicer for there to be one version only.

Thanks for all your great work!

:-Joe

[puremvc]

You are correct that it could be all be unified, but then it would be more complex than the user of one or the other needs.

And I do appreciate that migration of classes from one version to the other can be a pain but at least its straightforward work. Hopefully there won't be much of that, but I didn't want to force MultiCore on those who don't need it and make them migrate otherwise stable standard version apps just to keep up with the platform. They can choose to migrate to and/or develop new stuff in MultiCore as they wish.

I'm making an effort to produce both MultiCore and Standard versions of utilities where it makes sense such as the DeploymentConfig utility. If you happen to port a Standard version utility to MultiCore, let us know, and we'll put it in the repo and try to make it as easy as possible to get the same functionality whichever version you choose.

Thanks,
-=Cliff>

[jowie]

I'm sorry to drag this back up again but...

I've just realised that a few of my old utilities which were written in Single Core have to now be converted to Multi Core... It's taken me the last ten minutes to work out why I couldn't just copy and paste a line from another project for registering a utility mediator, and this is why.

So, as a company, we have made the decision to ensure *every* project, no matter what people are doing, is Multi Core. That way we will not have this problem in future.

But this is kinda my point... Having two versions of something that only really needs one version. And we really only need one version. If you want Single Core, how long does it take to create a key name?

I believe the principles of DRY coding skills may apply here...

   

:-Joe of the CMCOP
:-(Campaign for Multi Core ONLY PureMVC) 

[puremvc]

Hi Joe,

I agree that from the isolated perspective of the AS3 community, that doing away with the Standard 'single core' version seems reasonable. (Except that to force everyone who has written Standarf Version apps that don't need MultiCore would be forced to 'upgrade' to stay current. And that runs counter to the core principles of the project, namely 'bug fix to stability and leave it alone so people aren't always having to play catch up, as with most 'continuously improved' software.

The project has grown and now supports 11 different languages. For those where modular programming is not possible or makes no sense to implement, the AS3 Standard Version remains as a Reference Implementation.

And for quite a while we didn't have MultiCore versions of most utilities, though we do now.

And crying DRY isn't really applicaple here. You don't use both versions in a single app. You choose one or the other based on your needs.

I do agree that for AS3 you can categorically choose MultiCore regardless of the need for modular programming, and advocate it. You can unit test easier, and that's a win.

-=Cliff>

[jowie]

Okay, you win! 

I guess it's just a lesson learned... At least we know that from now on, using MultiCore for us is the way forward.

Thanks,

:-Joe