Architectural Atrocities, part 11: Not yet another namespace construct

Gumbo introduces many new classes, some of which are re-implementations of existing Halo classes (and thus have the same name). In order to disambiguate between Halo and Gumbo, Gumbo classes are prefixed to avoid collisions. Gumbo components that have Halo equivalents, like Button, List and CheckBox, are now prefixed with the letters “Fx”. This means in MXML, a Gumbo Button would be instantiated via the <FXButton /> MXML tag, and a Halo Button would continue to be instantiated via the <Button /> MXML tag. Additionally, the new animation classes in Gumbo also follow the same prefix policy. A Gumbo resize effect is instantiated via the <FxResize /> MXML tag while a Halo resize effect is instantiated via the <Resize /> tag.

From Gumbo Component Architecture

So what are they going to do for Flex 5, use “Fx2″?

Seriously, ActionScript has three* namespace constructs already, why introduce a fourth? Using prefixes is a hack to get namespaces in language that lacks them (like C or PHP), but packages were invented to solve exactly this problem.

In MXML it’s dead simple to use namespaces and prefixes to differentiate between different components with the same class name (e.g. <mx:Button> vs. <fx:Button>). The only place where it gets a bit messy is in ActionScript, but it seems to me that it is a fringe case when you want to juggle both a Halo and a Gumbo button or both a Halo and a Gumbo list in the same class (a Halo list and a Gumbo button, sure, but that wouldn’t cause a clash). I can see it happening, but not often enough to warrant such an ugly solution as this.

I remember when AIR was called Apollo and the WindowedApplication class was called ApolloApplication. This is the same kind of short-sightedness.

* Three namespace constructs: packages, namespaces and XML namespaces (which are different from packages since you can manually flatten a package structure with a manifest, e.g. the Flex namespace contains both classes from mx.core and mx.controls, and others).

Update: Adobe has decided to revert the decision of prefixing the new Gumbo classes. Good for everyone.

13 Responses to “Architectural Atrocities, part 11: Not yet another namespace construct”

  1. Ryan Christiansen Says:

    I’m glad I’m not the only person that hates hacking up the namespaces. I’d actually prefer it if the Halo library were removed and replaced entirely.

    In my opinion, holding onto every piece of legacy code solely “for compatibility reasons” just stunts the advancement of the technology and adds unnecessary confusion. Just let it go already…

  2. TK Says:

    Ridiculous. That was my first thought when I saw the new Flex 4 stuff… WE’RE USING XML FOR CRYING OUT LOUD! WHY NOT JUST INCLUDE A NEW NAMESPACE!?!?

    We do have three notions of namespaces in Actionscript and MXML, why do something so stupid?

    Soon it’ll have to be fully-qualified names for components, eg: lol.

  3. Andrew Odri Says:

    Yeah, this is annoying. I am a big fan of consistency in naming conventions, and keeping it logical and readable. I honestly don’t know how this got through – there is a some really smart people on the Flex team. I just hope this MXML/ActionScript doesn’t turn into another PHP4, where conventions get so inconsistent it begins to effect the architecture of your code. That would be sad.

  4. Ian Says:

    Sounds like a major pain in the ass.

  5. Richard Lord Says:

    I think it’s because of css issues – if the classes had the same name and you defined a Button style in css Flex wouldn’t know which of the identically named classes you’re styling.

    There is a method for specifying namespaces in the Css3 spec, but unfortunately this won’t be in the css spec for Flex 4 – implementing this would have been a better solution.

  6. nwebb Says:

    Agreed. Also see:


  7. Jay Says:

    Due to overwhelming community outcry the Fx prefix has been dropped from Flex4.

  8. Marcus Stade Says:

    Theo, what do you think about Adobe’s change of Application.application?

    While I understand their reasoning that by referencing Application from another Application type incurrs a bytecode size overhead, wouldn’t it be better to do away with this global variable altogether and instead provide a reference by injecting it into a property on each display object? Also, why typing it so loosely? Wouldn’t it be better to type the property to an interface so that the API is not hidden and so the implementation may change (ie, mocked).

    I think that Application.application was in itself a bad idea, but moving it to FlexGlobals.topLevelApplication and further justifying it’s existance is just adding insult to injury in my mind. Shouldn’t Adobe come forth and lead by example?

  9. Theo Says:


    you wouldn’t even need to inject it:

    protected function get application( ) : Application {
      var appCandidate : DisplayObject = this;

    while ( ! (appCandidate is Application) && appCandidate.parent != null ) { appCandidate = appCandidate.parent; }

    if ( appCandidate is Application ) { return appCandidate; } else { return null; } }

    it doesn’t work for pop ups, but I’m sure you can do some magic using stage and working your way down, can’t remember which order Flex puts things off the top of my head.

    I might have screwed up the exact test of the loop.

    To answer your question: it’s just as ugly as it ever was.

  10. Marcus Stade Says:

    True, that’ll most certainly work (except for, as you do note, Popups) but is unnecessary complex and doesn’t solve the typing issue at all.

    You’re still referencing a concrete class instead of an interface. Should your class not inherit from mx.core.Application (ie, spark.components.Application), you’re at a loss. Of course, it’s probably likely that when developing the application, the Application class is known, but when migrating a code base from say Halo to Spark this may well become an issue. Or when using modules for instance.

    As Matthew mentioned on the page I linked to above however, the application is already available to UIComponent through the parentApplication property which solves the issue of referencing altogether (too bad it can’t be mocked, read only), but not the issue of loose typing. But hey, they’ve got half’n'half =)

    I don’t care much for his explanation of FlexGlobals existance though, basically justifying it by saying global variables are ok and some sillyness about OO principal zealotry standing in the way of, well, quick’n'dirty access from classes not belonging to the display chain (making the classes lie about their dependancies instead). Oh well.

    On a totally unrelated sidenote, it’s been a while since an update on your blog. I hope you catch the time to update sometime soon, I always enjoy reading your insightful posts!

  11. Theo Says:

    I’d say that if an arbitrary component needs a reference to the top level application you’ve got more serious design issues that wether that variable is typed as an interface or a concrete type =) It’s just a bad idea to start with (which seems to be more or less what you’re saying).

    It’s true I haven’t updated the blog for way too long. Part of the reason is that I don’t do much Flex development anymore, and the other part is that that work has kept me quite busy (because it’s exciting stuff). If or when I get around to start writing this blog will have a very different focus.

  12. Marcus Stade Says:

    Oh I wholeheartedly agree, it reaks. But for the sake of argument, I still think that having a questionable justification for it’s existance doesn’t really excuse the blatant disregard for sane principles by making it into a global variable. In addition to that, separating it into a container class whose sole purpose seems to be holding global variables is just adding insult to injury since they probably think that there’ll be more “useful” globals around the corner.

    What annoys me isn’t really this particular case though. I can see why someone would do this in a smaller project where testability and maintainability is not really key (prototypes for instance). No, what annoys me is the fact that it’s right there in the framework. On the one hand producing articles about best practices and on the other shipping code that violates very basic “rules” if you will. I realise that best practices is little more than a guideline, there’s no silver bullet, but you’d think that at least the very basics would be nailed to the ground by now.

    I guess I’m overreacting a bit, sometimes I just get the feeling that Adobe’s more concerned about marketing a high level product than actually producing it. Flex is a good product, but design flaws like this are littered all over the framework making it difficult to gain traction with serious programmers who actually care about making quality software. It hurts.

    Anyway, sorry for spamming your blog, I’ll stop now. I’m really looking forward to hearing more about your current endevours as I always enjoy reading your very insightful posts!

  13. Theo Says:

    Agreed. It’s ugly.

    It’s was enough that Adobe took Cairngorm under its wing, that they now seem to have let the same ideas from that framework seep into Flex is just atrocious.

Leave a Reply