Fx prefix revisited

If this is a purely technical discussion, I deeply apologize for this non-technical post. I just would like to quickly second those who have raised the following concerns:<br /><br />1) Making millions of people type 'Fx' for many years in the future just because of a transition period = bad.<br /><br />2) Mixing Spark and Halo components in the same app = very very bad.<br /><br />3) In Silverlight and other competitors you can type new Button() or <Button> - not <MSDotNetButton> - why would the community expect anything less from the market leader?

Marcus,

I don't believe we are disagreeing. My point is that the namespace is not a hard thing to teach and we have been teaching it in Flex for years when someone dropped a custom component in a new directory.

I am pro namespace, anti-prefix.

Mike

@Dusty Jewett: Thanks a lot for the link, I didn't know about namespaces in CSS!

@Michael Labriola: As many have pointed out, maintainability must be the primary concern. In fact, trying to educate new users on the existance and use of namespaces will probably take a hit from the pseudo-namespacing technique that prefixing provides, proving counterproductive no matter what marketing thinks. New users, when they grok the namespace concept if they didn't already knew about them, will probably realize by themselves that prefixing instead of relying on namespaces is a hack.

Did anyone consider that this "solution" might very well lower one's expectation of the quality of the framework itself? I mean, if the vendor of your dev tools can't even get namespacing right, what else is a hack? Sure, such a point of view might be a bit grim, but is it really that far fetched?

Besides, has anyone done any actual research into this issue, any user testing? How difficult is it to grok the namespace concept, really? I personally think that the whole issue is make believe, creating a problem where there is none and in doing so upsetting it's community.

@Dusty:

I believe Simeon already, by himself, made a working copy of the framework sans prefix. I don't think this is a decision regarding whether they ship this year or not. Altough, that might be the source of some problems.

This is basically an issue of maintainability going forward versus the ability to educate new users in the short term. I favor educating someone instead of being painted into a corner.

Mike

My main point is: Developer time is finite, they can only do so much, and without community leaders saying that they'll put their hours where their mouths are, Adobe may have to decide whether they want to ship Flex 4 in 2009 or remove the prefixes

I don't support the removal of the prefixes, but I WILL support a community effort to work on components so that Adobe can focus on what the community requests and still ship in 2009. I don't have the rockstar status that is needed to start such an effort, but whichever rockstar does, consider me your first volunteer.

P.S. @Marcus:
Namespaces are a CSS3 spec, no need to make up your own syntax:
http://www.w3.org/TR/css3-namespace/

bMy proposed answer to this issue can be read at the bottom of this post, as the post itself is quite long.

@Dusty Jewett: "Right, so I'll admit that I got caught up in the hyperbole surrounding this issue, but I guess I was trying to point out that there are issues with readability, scanability and noob-ability with BOTH solutions, and that the common 'argument' against prefixes is that "it looks bad" or "doesn't feel right", rather than an actual technical argument."

Quite frankly Dusty, your posts actually confirm WHY a prefix is useless. While you argue that the community opinion is that "it doesn't feel right", your argument is very much the same, albeit from a cost/benefit point-of-view. You don't want to fully qualify type names because it hurts readability and development time. This is fully acceptable I think and the reason why numerous other languages have the concept of aliases. This is probably best served with a pseudo-ActionScript example:

import mx.controls.Button as MxButton;
import fx.controls.*

function foo():void
{
var myButton:MxButton = new MxButton();
var otherButton:Button = new Button();
}

Using this method, you please proponents in both camps, keeping the namespaces but still being able to disambiguate collisions. Furthermore, it not only makes the API clear and consistent (no meaningless prefixes which are really namespaces anyway), it puts the power to name types where it belongs: with the developers. This way, a developer is able to provide contextually relevant aliases. For instance, Fx as a prefix is meaningless, where as for instance Skinnable is not:

import mx.controls.Button;
import fx.controls.Button as SkinnableButton;

function foo():void
{
var myButton:DeprecatedButton = new DeprecatedButton();
var otherButton:SkinnableButton = new SkinnableButton();
}

In addition to this, the SDK team definately should consider making better use of the Deprecated metadata tag. The reason to use such a tag is to make the compiler let users know that a class is now considered deprecated and will disappear from the next version of the framework. This gives the developers ample time to migrate from the old version to the new.

The bottom line is that Adobe's "solution" is a mere hack to solve what is considered a difficult issue. Where the difficulty lies is I guess anyone's best guess, only Adobe knows. I can't imagine that whatever is decided upon as very difficult to implement, I suppose the problem is agreeing upon a specific solution. Therefore, I'd like to offer my opinions on this issue:

1. MXML has namespace support, it's the perfect tool to disambiguate names. MXML also has the ability to require inline usage of a namespace prefix with the syntax:



Where ns is the namespace and Element is whatever element is used. This works to disambiguate names inline. I.e.:




2. ActionScript has namespace support, again the perfect tool to disambiguate names. However, ActionScript currently lack the support to, efficiently, disambiguate names inline. To do this currenly, one has to fully qualify the type name:

import fx.controls.*;
import mx.controls.*;

var myButton:mx.controls.Button = new mx.controls.Button();
var anotherButton:fx.controls.Button = fx.controls.Button(event.target);

This hurts developer efficiency as it reduces readability and increases the amount of typing necessary. To remedy this, a way to provide an alias for a type is suggested:

import mx.controls.Button as OldButton;
import fx.controls.Button as Button;

var myButton:OldButton = new OldButton();
var anotherButton:Button = new Button();

This syntax is backwards compatible as it doesn't break existing syntax. It is also contextually efficient as the alias is declared along with the import statement. The syntax does not support providing a whole package with an alias, but I doubt that there actually exists a real-world case that supports the need for such a feature. The ability to provide an alias for an import statement could very well be a Flex-only supported feature, considering the fact that Flash CS4 is already released. Support for such disambiguation could be added to the compiler used with Flash CS4 at a later time through a software patch or other update. Compilerwise, this might work as a pre-processor step, replacing any aliases with the fully qualified name. Someone with better insight into compiler architecture (Flex SDK team) will be able to answer that issue.

3. CSS does not support namespaces. There are a few ways to consider an approach to disambiguing name collisions in CSS. One is to ignore it altogether. CSS, as the name indicates, is cascading. Any styles that are not implemented by a component is effectively ignored. Thus, styles for old Halo components and new Spark components can co-exist in the same type selector. This means no further compiler development is necessary in order for CSS support to be fully functional. However, this can lead to unnecessarily complex CSS:

Button
{
/* These styles are supported in Halo */
[...]

/* These styles are supported in Spark */
[...]
}

Wether this is a real life issue or not remains to be decided upon, but fact remains that CSS works as advertised. In the end, this is most likely a non-issue. The second way to consider is adding namespace support to CSS. This might provide useful, but might also be a lot of effort in return for little benefit. Such a syntax could resemble the ActionScript syntax:

use mx.controls.Button as OldButton;

/* Spark component */
Button
{
[...]
}

/* Halo component */
OldButton
{
[...]
}

However, this is a solution which could very well lead to further confusion and complexity. Furthermore, it makes Flex CSS even less compliant with the standard. Also, any namespace solution that makes use of the colon is likely to be even more confusing if the standard CSS use of colon (ie, states) is implemented:

fx.controls:Button:hover
{
[...]
}

Readability is compromised and this solution is very much likely to cause further confusion with more complex situations:

Group fx.controls:Button.someStyleName
{
[...]
}

In my opinion, the optimal solution is to leave CSS as is. It works and it works well. Any style that is not supported will silently fail. One must also remember that there are selectors other than the type selector available which can be used for disambiguation. Overlapping styles is possibly an issue, but quite easy to overcome with the inherent ability to provide style classes. Again, CSS inherently solves a lot of these issues by simply doing nothing at all where a style is not supported.

4. ASDoc output supports namespaces. This is a non-issue. ASDoc already parses the package structure of classes. In the event of a flat listing of classes, deprecated classes should be marked as such, which solves the immediate problem of Halo vs. Spark-classes.

5. Namespaces might be difficult for new users to understand. This possibly rings true to developers of a language where the concept of namespaces does not exist. However, prefixing some classes does not help in making a new user understand the concept of namespaces. Rather, it makes it even more difficult. Let's for arguments sake say that a new user comes along and doesn't understand namespaces. You try to explain that they exist as a way of disambiguing between type names, effectively aiding in avoding name collisions.

Surely the novice user will ask, why then are there some classes that are prefixed and some that are not? For what is a prefix but a way of providing a namespace? Prefixing (or suffixing) type names also goes against best practices in naming conventions, where it is recommended that type names are logical and concise to avoid confusion. Prefixes merely adds complexity, may well seem illo

adding a voice and trying to be brief...

My position is that namespace is the right place to handle this, and we need to be smart about handling the knock-on effects.

+1 for the points as presented by Tink.
+1 for Simon Bateman's notes.

I also think the points presented by Manish Jethani's (second post) raise the spectre of revisiting the issue for Flex 5 and beyond if you were to prefix the class name.

RE flex documentation - icons in the page headers would be nice - and cross-links to equivalents in other namespaces to go straight there if we found ourselves on the wrong Button page for instance would be handy.

I'd caution against over-weighting concerns re new 'users'. Accelerating their learning may provide an initial benefit on their first projects, but if it subsequently presents a net hindrance over their development life it is not worth it. Better to concentrate on doing the 'right thing' and educating.

I'd be happy with the separation of namespaces as described by Peter Farland.

my two cents
How often do we need to mix Halo and Spark components to create one mxml file. I believe since Flex 1.5 we never used a mixed namespace files. do we ?
And if this is the case then it will be an obvious condition where we will have either a true Halo or Spark MXML file having proper compliance to its corresponding name space. In actionscript we may have different package path i.e. mx.controls.Button or fx.controls.Button separating themselves from each other.

I would recommend having different namespace declaration rather having Fx prefixed.

Anand

I would go with Constantin and Arnoud here

if you look at it from the 10000 feet point of view, the "fx prefix"
is a problem only because it is an intermediary measure

if you forgot for an instant that Flex 4 have to be released even if
spark is not ready

what feels right would be to release Flex 4 when spark is ready,
and if that happen, there's no need for an "fx prefix"

so ok it's a long shot
but really it would be nice if Adobe, not only the Flex SDK team,
could think about the "waste of time" for all the users of Flex in general

does it worth the trouble and the confusion to not wait for when spark
is complete ?

cheers,
zwetan

To follow up with questions raised after my 1st post:<br /><br />b Namespace Composition<br />mx: would continue on with the http://www.adobe.com/2006/mxml as it stands today with no additions or removals.<br />fx: would contain all of the new spark components and none of the halo components or language elements.<br />The default root namespace would contain only language elements. Nothing that is likely to change in the future should go in here though. Well always have <script>,<medatadata> etc but you end up creating confusion if you put HTTPService in this one and later need to break backwards compatibility. Id also be willing/like to see these faceless elements go into some 3rd namespace.<br /><br />b CSS Collision Issue<br />Although Im not a fan of using the top level selectors (Button) in CSS, Id say that if any namespacing needs to be added that it should not be needed for existing Halo components or existing code will break. Instead, Id say that if no namespace is given it would first apply to the mx component and if not found fall over to the fx version. If you want to mix components types in the same application you will need to add a namespace for the fx version but it would remain optional if you only had Spark components in your app. All the default styles should probably have the fx and mx namespace added so they applied to the mixed environment correctly.<br /><br />b Flex Builder Behavior<br />Youll probably need a maintain Flex 3 Compatibility flag that can decide the precedence for code complete. If this is set new components are are created with the same template as today and the mx namespace takes precedence. Without it set, Flex Builder can then automatically add the root and fx namespaces to MXML when you create a new document. FlexBuilder will then automatically add the mx namespace should you use the one of the halo components not in spark. If you want to explicitly use a Halo component you can always start with <mx:. If things are not far enough along for Flex4 that you do not always need the mx namespace it could also be added by default. <br /><br />b Existing Flex 3 Projects, Examples and Tutorials <br />Existing Flex 3 code should remain intact and all Flex 3 examples the net should still be valid if you copy and pates them. <br /><br />b Migration from Flex 3 to Flex 4/5 (justification): <br />The reason the namespace makes since to me is that when Spark components reach the level of maturity my application needs I can change the namespace over with a find replace and then go about correcting the points where backwards compatibility are broken. The compiler will give me a good idea of what needs fixing. In theory I wont have look at every single element and have to decide if I need to append an Fx or not to the name. With the Fx prefix I will never have an easy way to tell if Im 100% transitioned to the new component set. If the 2006 name space if removed then I know Im done.<br /><br />b Readability (justification)<br />Maintaining the namespacing convention will always always make it clear which version of Button is being used. If I see an code with mx I know halo if I see fx I see spark.<br /><br />b Expanding the Component Set or adding new ones (justification)<br />New Spark or even a 3rd future set components can be added without any concern of what components exist or what they are named in the current set(s). <br /><br />b Lasting Impact (justification)<br />The issue we are discussing now will never have to be revisited if namespaces are chosen. If the 3rd Future set is for say mobile then converting to a mobile version of app is as simple as changing the name space and addressing the missing or extra features. If the Fx prefix is used and Halo is a memory then someone will almost assuredly say Why not just call it Button when adding the next set. The Fx prefix basically only gets you past today. You use namespaces now all the justifications used today still hold true 5 years from now.<br /><br />b Heats and Minds (justification)<br />With Silverlight and JavaFX chasing Flex and trying to drive developers in their direction. To a new developer seeing an obvious hack from day one and almost every time you define a new components only gives the competitors an opportunity that doesnt have to exist. A year from now this transition period can just be just a memory to those of who were around and would never be seen by a new Developer using Flex 5.<br /><br />b Namespaces and Packages already exist (justification)<br />This doesnt necessitate the creation of language constructs that dont already exist and are not already widely use. Different packages for like classes with same name is already the norm.