Prefixing Fx

Adobe’s Flex team seems inclined to move away from clean design.

Flex framework’s current stable version is 3.x and the Flex team at Adobe is actively working on getting the version 4.x ready this year. At this time, the core SDK of Flex 4, codenamed Gumbo, is evolving through an open source process. From peeking into its initial version, it looks promising as there are serious attempts to create a clean separation of behavior and presentation in the components, apart from the tons of nifty enhancements throughout the framework. (I promise to write about some of the forthcoming features soon)

However, one design decision in the midst of all this goodness seems rather odd and alarming. The Flex team is proposing to prefix Gumbo component names with the letters “Fx”. Lets try and understand what this means.

In Flex 3.x and 2.x you have a button component, which you access within a flex application using ****. Here the name of the component is **Button** and **mx** is the namespace within which this component resides. Now in 4.x you still have the Button component but it deviates majorly from the component by the same name in the 3.x or the 2.x version of the framework. Its possible developers may like to use both versions concurrently and that’s where there is a need for the two entities, i.e. buttons, (with the same name) to be identified distinctly.

Simply said, how do you make sure the two versions of Button work together without causing confusion in the program. The answer to this question is simple and time tested: Put them in different logical buckets. 

This solution of putting things with same names into logically diferent partitions seems to work well in many situations. This is how two classes by the same name are differentiated — they are put under different package structures. For example a.b.c.Foo and x.y.z.Foo can co-exist as far as they are referred with their fully qualified names. This is how XML elements with the same name but from different schemas are reconciled. This is how variables with the same name but within different scopes are resolved.

However, this simple solution seems to evade the Flex team’s considerations. They believe logical partitioning (which translates to namespaces in the case of Flex components acessed by their XML tags) can be confusing for the beginners.

 

Common Sense Reasoning

So they propose instead that we prefix the names of all components whoes names clash with existing ones with the letters “Fx”. In other words our in Flex 3.x or 2.x, which by the way is affectionately now called “Halo”,  becomes in Flex 4, which is also referred to as “Gumbo”.

If you use namespaces instead then this same Button in Gumbo will be ****.

If we follow Adobe’s suggestion we may land up with something like this —

• Halo — mx:Button
• Gumbo — FxButton
• Mumbo (or whatever they choose to affectionately call the next version) — Fx2Button or FxFxButton or MumboFxButton
• Jumbo (possibly the following evolutionary version) —  Fx3Button or FxFxFxButton or JumboFxButton

Would you not just call a button a Button and have the namespaces decide weather its from the Halo, Gumbo, Mumbo or Jumbo clan?

If you would like to help Adobe make a sensible decision in favor of namespaces (i.e. using fx:Button instead of FxButton for now) then please go ahead and vote for this bug on the Flex JIRA.