Some thoughts about the need for packaging in Dart.

Yesterday, I spent about 4 hours working an exploratory refactoring of the Dart PureMVC port and then reverted all of it.

The Original Problem:

PureMVC contains a couple of classes whose names conflict with classes in the dart:html library. As a result, if you import both libraries, you can't compile.

To resolve the conflict, you must either ...
1) Avoid use of both libs in the same program. (err, no.)
2) Make developers prefix one of the libs on import and add to all class and interface uses in code. (ugh. mvc.Notification or html.document everywhere, even for non-conflicting classnames).
3) Name your class something different. (grrr. MVCNotification instead of Notification)

As much as I hate the wild west, claim-staking feel of number 3, I accepted the compromise. They owned Proxy and Notification because they got there first.

So yesterday, I refactored the framework from my original go of MVC-prepended classnames to the normal classnames, and used prefixing the way that +Seth Ladd suggests about 22 comments down into the comment thread of the attached post.

What I verified was that Option 2 above would've been almost equivalent to Option 3 EXCEPT that my interfaces (IProxy, INotification) don't conflict with any Dart classes, so they can still be named the same as they normally are. And, it places extra work on the developer to have to use the namespace for every PureMVC class (or dart:html class) even if it isn't in conflict.
In AS3, packaging a class allows us to have a unique namespace for groups of classes, and classes with the same name but a different namespace are always ok. No need to prefix every class or interface in a library when referencing it in code, only if it's a class in direct conflict do you have to fully qualify one of the classes).

For an idea of how packaging could work in dart, check out the source for one of the offending classes, first in Dart, then in AS3:

PureMVC Dart MultiCore Source
PureMVC AS3 MultiCore Source

#dartlang #puremvc
Shared publiclyView activity