March 21, 2007
Names are important
For a profession that is all about naming things, most programmers are being terribly careless with names. Although you get away with it most of the time, you look so immensely stupid when two pieces of code disagree over the meaning of a name. Names are important.
One of the things I still love about Perl is that, by convention, it is considered rude to invade other people's namespace. So we put all our public methods and constants into the @EXPORT_OK array and let the client decide which part of that he wants to use in their code. I should be able to do the same with code extending existing classes: Let me decide which extensions I want patched in on a per-class basis. I believe extension methods in C# 3.0 work this way. Do copy this.
Another name issue few languages get right are namespaces. Namespaces are important, because sooner or later you will have two different Node classes in your project and you need to tell your code which one to use. Let's look how some popular languages are dealing with this:
- PHP
-
Bashing PHP is a bit like beating up an old man, but here we go anyway: PHP has no notion of namespaces at all. To work around this, people are using
Really_Long_Classnames_With_Packagish_Names_Prefixedto lessen the chance of namespace clashes. LOL. - Java
-
Has a wonderful culture of putting classes in packages named after some domain you own. So my
Nodeclass would be packaged asorg.netalive.swsu.Nodeand people couldimportthis name and just writeNode. Bad: When you need to use two differentNodeclasses in the same piece of code. As you can only import oneNodewithout name clashes your code will look likeMap<Node, incredibly.long.package.name.of.other.Node>. Horrible when it happens, and it happens frequently. For instance, both the most basic GUI widget in Swing and the most basic data structure in Java are calledList. - Perl and Ruby
-
Uses
Package::Subpackage::Classnamesyntax for improved looks, but since you cannot import or alias these long names, this is more about organizing files and not really better than PHP'sPackage_Subpackage_Classnameworkaround. At least you can switch into a namespace and add and replace methods without using fully qualified names. It's kind of OK for untyped languages because you only need to reference types when calling a constructor or another static method. Still the possibility of anotherTree::Nodeclass in a second library is always there and sometimes urges you to use more unique package names than you would like. - Python
-
I don't speak Python, but from what I've seen this is a language that got namespaces right. You can import a namespace as in Java, you can selectively import symbols as in Perl, and here's the goodness: You can
import reallylongmodulename as shortcutto aliasreallylongmodulenameintoshortcut. Nice.
I think what Python does (importing and importing into aliases) should be the minimum requirement for any language that wants to take names seriously. The package naming convention from Java is cool, because the DNS is the only naming scheme humanity ever reached something like an agreement over, and unique names are good. Imagine blowing up the planet because some piece of code felt ambivalent about the semantics of System.Nuke. We would look all kinds of stupid if this sort of thing ever happened.
Comments
As usual a superb post and to the point. I'm primarily a PHP programmer for the web (I dabble in Perl rarely) and hate the fact there's no namespaces. PHP takes this even further - library functions aren't named in a standard way (i'm talking the standard libraries here) - it's no wonder there's so much messy PHP code out there - the language itself doesn't encourage good practice (type-less anyone?)
In fact, I think the typeless nature of PHP is the single worst thing about it. And something I use with glee! </hypocrite>
Oh by the way - nice to see more frequent posting here again.
Posted by James Booker (#)
In case of doing OO in Perl, though, note the handy aliased module. (The way it works is actually so trivial that you don’t need the module, but using it lets you write the same thing in an intention-revealing fashion.)
Posted by Aristotle Pagaltzis (#)
Very nice module. I remember trying to write something similar some years ago but gave up in frustration.
Posted by
Henning Koch ![[TypeKey Profile Page]](http://www.netalive.org/swsu/nav-commenters.gif)
(#)
"You can import reallylongmodulename as shortcut to alias reallylongmodulename into shortcut. Nice"
I didn't know about that (I've only scratched the surface of python). I don't think I'd like to see it in Java though. It is essentially a macro, and although it is limited to a single specific use, the purist in me says "No". Using it would nullify the benefits of the unique package based naming convention for Java which you described.
Also I can see it being abused in horrible ways. Perhaps if it were limited such that it were ONLY allowed in cases where two classes of the same name are imported.
Given the relative rarity of class naming conflicts in Java (in my experience anyway. I almost always give my classes names with at least two words), a little verbosity in differentiating types where they appear (variable declarations and function headers mostly, perhaps the odd cast) it doesn't seem like a big deal. My two cents.
Posted by Bruce Sutherland (#)
Come to think of it, I can think of one way you could achieve something like "import reallylongmodulename as shortcut" in java.
You could declare an inner class which extends the class with the really long name.
To use your example with the AWT List and the List data structure:
package my.domain.my.package;
public class MyClass
{
public class AWTList extends java.awt.List{};
public class UtilList extends java.util.List{};
... rest of class code
}
Posted by Bruce Sutherland (#)
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)
