I've been professionally programming for more than 20 years [1] and I've never needed to use a namespace.
I do know what a Namespace is. I think I shouldn't have.
Rarely, when the compiler cannot figure out what variable or function I'm referring to, it just signals an error and I fix this by writing the qualified name. That's all there is and there should be to it.
Of course namespaces can be there as leaked abstractions of implementation details. Ideally, a programmer should not know about them [2].
Why? Because, they don't help much, don't have much use, They are extra things to learn and complicate things unnecessarily. (Objects as abstractions actually help programming, Namespaces don't). (And there are XML namespaces, which I don't like in a different way).
Namespaces in a programming language solve an artificial problem and they create a bigger problem than they solve.
Still you may like them. But if that's the case, can you tell me how these fit in a scripting language that doesn't have a pointer type or memory management (by user)?
The first time I heard about 'Advanced' data structures called linked lists(!), I was surprised but later this made sense [3].
ActionScript should be simple. A namespace soup complicates things without much, if any, benefit in return. I don't think any language needs a spelled out Namespace type but scripting languages more so [4].
But we do have namespaces in AS3. I'm not proposing that they should be removed (Backwards compatibility is important). They just should not be made to look like a fundamental property of the language. Someone who has never heard of namespaces should be able to program in AS with no side effects caused by language design. This will make AS better than the rest [5].
Luckily, currently the situation is not hopeless, you can do without namespaces most of the time. What I'm afraid is the future directions.
I call namespaces the unnecessary evil …
[1] Actually 21. I've programmed in Basic, Z80 and 80×86 assembly, C, C++, Delphi Pascal and briefly in Cobol, Fortran, Lisp and Prolog. I won't bother listing numerous scripting languages.
[2] C++ has many features that many programmers don't know and care about. You can do without them and this is totally OK with me.
[3] Linked lists are simple data structures, not advanced.
[4] In AS3 there are some features that make use of namespaces which IMHO should have been implemented in other ways.
[5] Computer language design is my hobby. It's one of the two subjects I feel like I'm truly qualified to talk about. Of course, you are free to disagree. But my thoughts on language design has many years of background and it's unlikely that I will change my opinion on namespaces.
Loading ...
While I may not be as far over as you in thinking they are totally useless, I do HATE the Java style of com.company.namespace. That is totally stupid, and just based on fashion at the time (urls were in vogue). Made worse by the fact that Java requires a matching directory structure, yuck. Yeah, people will never change urls or sell software, cough cough.
Interestingly I recently have had a few situations where a Flex app compiles fine for me, yet a team member has conflicts with classes with the same name in other namespaces (same synced code, we can’t explain it). So for all the hand wringing, it might be better to get them to actually work properly in Flex first : ).
I haven’t really thought about not having namespaces at all. I’m not a big fan of prefixes, but I can see that is probably a preference. And I must admit there are times when I’m not sure whose Rectangle and Point I’m dealing with — there are namespaces to help with that, and then imports to immediately undo that help. Probably I could live without them, I agree that they are more useless than one would think they should be (really the assembly/package should never have a duplicate name, that should be a language rule imo, in which case you wouldn’t really need them I guess).
Accessors (get/set) are another thing I thought was great at the time, but these days I tend to use public fields. It seems real handy to make a method look like a field, but really why would you want to introduce the confusion. I think a lot of these things are cheap ways to make tooling and printouts look prettier.
Interesting post, I’m not quite in your camp, but definitely mulling it over : ).
Hi Robin,
> I do HATE the Java style of com.company.namespace.
You are not alone. I wonder if it did attract enough Java developers or helped enough with migration from Java, and so if it was worth it.
In my everyday use, 90% of the time I’m dealing with members of a class, and so the variable that holds the pointer to the object instance is all that is needed for proper qualification.
Name collisions, if any, may occur at the very top level. 99.9999% of the time, what I import/include/use don’t have any collisions. Libraries/components I use, use prefixes if their top level classes have somewhat generic names. But this is, again, most of the time redundant because even if they use generic names, I wouldn’t be normally using such two components from a single file.
I usually define an object type with “t” or “o” prefix. Then I define a pointer to that type with “p” prefix, which will be the type I will actually use when creating the object instance.
My point is that namespaces are abstract implementation details that does not help the coder to code better.
“I import/use/include this file/library” is what the coder should know and care about. Thinking in namespaces doesn’t improve anything. If there is a name collision then you should use the qualified, longer name. That’s it. That’s simple. Why should you deal with abstract entities called namespaces, when it does not return back any benefits?
If *all* your code was in a single file, you wouldn’t be able to declare two different things with the same name and there wouldn’t be any namespaces (the only namespace would be like air you live in and don’t know about) [Of course I'm assuming you are not using namespaces as access specifiers, creating namespaces out of nowhere]. That’s the simplest case, and that’s IMO is the goal simplicity level. How much should you be inconvenienced because you have your code in separate files and name collisions are allowed?
Best,
Burak
The reason why you’ve never worked with namespaces is looks like you’ve never really had to deal with a templating engine like MXML, according to your resume. In Flex4, Actionscript is NOT getting namespaces, only the MXML piece. It is essentially the same as a fully-qualified-object-name in AS or C++ ; you can’t do fully qualified names in MXML or other templating engines.
Hi Nick,
Thanks for the comment.
> you’ve never really had to deal with a templating engine
This may be true. And I feel fortunate about this.
> In Flex4, Actionscript is NOT getting namespaces, only the MXML piece.
I do understand what is getting the namespace. Actually the reason I posted this entry was to make my point clear.
Simply: I don’t think namespaces are a good idea in general, so I don’t think a solution using namespaces is ever better than another solution not using namespaces.
In AS3 there are namespaces. I’m content with the current state.
But I’m not OK with the idea of ‘solving problems using namespaces’ approach, because this may, in the future, make AS3 harder for the new-comer. And personally I’d hate to deal with namespaces.
Best,
Burak
As a counterpoint to the uselessness of namespaces: flash_proxy.
Hi Steve,
Thanks for the comment.
flash_proxy is a great example of ‘solving problems with namespaces’.
Namespaces, in my basic understanding, define name scopes to avoid name collisions. As a *concept*, every file or unit of programming will intrisically define its namespace – you won’t need a namespace type.
When you have a namespace type, as an abstract entity, now not bound to physical files or basic logical units, you can make use of them more and more (and sometimes not in a consistent manner).
For example in AS3 you use them like/as access specifiers.
This is the exact usage I’m against. (As long as you can ignore the usage, I’m OK with it though).
In Proxy class, methods are defined in flash_proxy namespace. If you will be using the class, you should learn about namespaces.
It serves a purpose, but it could have been implemented in other ways, which IMHO would be better.
I really can appreciate the elegance of namespaces. Sometimes I write a very elegant routine and I feel sad when I replace it with a better one not so elegant. But I try to be rational.
In AS1/2 there were no such namespace issues. Someone listed the top reason to move to Windows 7 [from XP] as ‘It will have XP in it in a VM’. flash_proxy solves a problem that wasn’t there in AS1/2.
I can work with namespaces. I just think they are not worth the trouble. (and, as I’ve written before, in a scripting language more so).
Practically, I’m OK with the Proxy class, you may call Proxy class usage as ‘advanced’.
What I really, really don’t want to see is namespaces imposed in ‘basic’ usage.
Best,
Burak
Namespaces can be useful in some cases…
This video tutorial shows a good example of it http://pv3d.org/2009/01/30/actionscript-3-namespaces/
Hi RooTShell,
The tutorial is nice.
These are what you get when you have a namespace type. It may look cool and it may even come handy at times.
But same results can be easily achieved in other ways.
And IMO Namespaces used this way, don’t solve any real problems.
Again this is my opinion, and though my ideal language won’t have a namespace type, I’m OK with them (as in AS3). I just want it to be a really optional feature.
Thanks,
Burak