Prefixes vs. Namespaces… Why would the prefix solution have scaled better?

Update (2009/06/02): It turns out some of my understanding about
this issue was wrong. I've never been a Flex guy. I will keep this post
as is below. My current understanding is that "promoting components to
the global namespace" was not a goal, but only a side effect. Albeit
a very important one IMO. So, this post still has a point.

The prefix solution would have scaled better? Yes. And this does not contradict with what I wrote about how similar both are, in my previous post.

With current namespace solution, every new major component-set version will get a new namespace. Does that solution scale well? What will happen with the 100th major version? (I'm aware that probably we won't see 100 major versions, this is a way of thinking to test if the solution really scales or not).

How are major versions decided? Arbitrarily? It seems so, because you can mix both versions we have now. Maybe "arbitrary" is not the correct word, but I can say "not rationally from a certain point of view".

What will you do when you have 1.01 bug fix version of a single component? You will replace the old one (overwrite). OK, what will you do when you have the 1.3 version of the component that is not compatible with the old version? Overwrite and you will break old apps, rename and you will get a new component. OK, not a big deal. What will you do when you have version 1.9 of the component, which is not compatible with the old version and is on the verge of being a new major version? Is changing the version to 2.0 and opening a new namespace for new version of component the best solution?

What will you do when you have major updates of some components, but not all? Put the new components in a new namespace, and let users use the current (but old) version components from the previous namespace? (This is the current situation – namespace soup in formation, it's manageable for now).

Namespaces, are like file system folders, that's how I visualize them most of the times.

Namespace solution does not scale as a whole, it does not take care of name collisions caused by minor updates, it doesn't really take care of major updates.

Actually, I think this could be a text book example of a solution which does not scale well at all.

"Put the new files into a new folder" is a simple solution (so far, so good). You can't expect it to solve all your problems, you can't expect it to scale well. It just keeps your root folder clean and, yes, it provides some level of organization, though I'd call more arbitrary than rational.

And this is the current policy, thanks to community feedback.

Is there a better solution? I think there is, and if prefixes were used, that solution would have been reached inevitably.

Global / top / root namespace is not different than other namespaces, but in one aspect. You can have only one of it.

My better solution applies to all namespaces, including the global namespace. (That's a good sign that the solution makes sense).

Here's is the solution:

- Have current version of components in one namespace.
- If there's an update to a component, that is not compatible with the current version or if you need to keep the old functionality for some reason, move the old component to a new, child, namespace. (Remember the XML class?)
- That's it. What's left is just deciding on a naming convention for new namespaces, which will host old versions.

This way, current version of components are always in a single namespace. One namespace to rule them all, no need to deal with multiple namespaces. (And if you use the global namespace [1], no need to deal with any namespace at all).

You may think that this solution can cause problems when migrating old code. Every solution has its drawbacks. You have to prioritize your goals. It may seem it's better to have old code compile as it did and then upgrade to new components step by step, or, maybe it's easier using new components by default and then fixing any problematic areas and even falling back to older versions if necessary…

Some code was compiled with a certain version at a certain point in time… I don't consider it as the top priority, to be so much backwards compatible that it should compile the same now and ever, without any effort.

Backwards compatibility is a tricky subject, I'm all for backwards compatibility, but when not done wrong.

This solution scales well, because you don't have to know about any other namespaces unless you need to use an older version of a component. If you have a total breaking change with the whole component set, not compatible with the older version in any way, then you should move the old version to a new namespace and have the new version where it should be (that is, the one and only namespace where you have your current version). Not a special case. Simple and simply beautiful.

(You can still apply this solution to the current namespace components are in),

Anyway, you can argue if this solution is better or not (I really don't have the time to elaborate on this at the moment).

If prefixes were used, in the global namespace, this solution would be implied, as you can't open another global namespace for a new set of components, and it will easily occur to anyone having Fx2, Fx3, whatever prefixes is not a good solution. (But somehow people think having new namespaces like s1, s2… is better [2], or will not ever happen – and you could have chosen a one letter prefix too).

In summary, IMO namespace solution not only ruined the initial goal (of promoting components to the global namespace), it ruined the way how new components should be handled. Welcome to the namespace soup!

[1] Obviously I'm assuming there will be one set of components in primary use.

[2] With namespaces, compiler can ease some syntax issues. Nevertheless, if you are in a position to use Fx3 as a prefix, then s3 would be the correct corresponding namespace name to use.