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: new package structures in 2.0  (Read 7419 times)
gabon
Jr. Member
**
Posts: 14


View Profile Email
« on: March 11, 2008, 09:50:45 »

Maybe it's me, but why would you change the packages including the package "as3" ? Could it happen that you have different versions in the same project (library)? This definitely doesn't help the porting of applications to the new version.
I was going to try, for instance, to see if a bug was fixed in the last release but changing all the classes namespace is not that tempting :)

Thanks, chr
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: March 11, 2008, 11:58:41 »

Believe me, I did fret about this a bit. I even thought about only including the language in the other versions but that seemed unbalanced.

But this release also needed to handle the Mediator naming strategy, which was clearly a pain, and everyone, including myself forgot to override getMediatorName about half the time, so it was clear there'd be some backward incompatibility.

There were all these ports getting started and support for them was being set up at the time. And that had its impact. If I did not do this now, then to do it later would force yet another required migration, but this time across multiple ports, demos and utilities and that would be a far nastier process than this.

And, though we may not have everything in the same library, there will be plenty of programmatic manipulation of the codebase, including scripts that check out code from every repository and create a uniform source view output.

Also a code snippit found in any context, such as a blog entry, documentation, or a book that talks about PureMVC and uses examples from several ports would be clear on sight as to the language its written for.

So in the end, maintaining an unambiguous package space seemed appropriate.
-=Cliff>
Logged
Pages: [1]
Print