zerosum dirt(nap)

evolution through a series of accidents

zerosum dirt(nap)

Why Namespaces Are Important

April 17, 2009 @ 03:11 PM by nap · 4 comments

Apparently both Extlib and the Mash library, which the latest version of the Twitter gem relies on, both define Mash as a top-level class. This is lame.

It means that if you're building an app that uses the Twitter gem to poll their API, you can't use DataMapper (which relies on Extlib) for your ORM. This is but one example of an affected application, of course (retweet stack trace). Integrity's twitter notification support is another victim. Epic namespacing fail.

So whose fault is this? The Mash library? Extlib? Which came first? Which is more widely used? OMFG fight!

Seriously, who cares? If you're asking yourself these questions you're missing the point.

module Org
  module Zerosum
    module Util
      class CollisionPrevention
        def initialize
          puts "gtfo"
        end
      end
    end
  end
end

Java users, and consumers of other modern programming languages, figured out why namespacing was important a long time ago. In fact, one of the few things I actually liked from the Java world was it's use of hierarchal domain names in packages to ensure class name uniqueness and prevent this sort of ugly namespace collision. It's simple and effective. And yet we don't see a strategy like this in use in Ruby gems all that often. It's not like Ruby doesn't provide us with a mechanism for it; Modules provide a really easy way to accomplish this. So why aren't we taking advantage of it in our libraries?

I don't mean to single out Extlib and Mash in my rant here -- I'm just picking on them because they happen to demonstrate an obvious problem that we've all run into on occasion. Hell, I'm guilty of it too. Anyway, the bottom line is, that if you intend your code to be sucked into someone else's application and reused, please do your best to prevent obvious namespace collisions. It's as easy as A::B::C (or Tld::Domain::Feature::Specification).

Thanks for listening! :)

4 comments so far ↓

  • ActsAsFlinn // April 17, 2009 @ 03:27 PM

    Agree, though I've never been fond of fqdn based namespace... just cause it's fugly not any real technical reasoning.

    Some of the initial rails plugins did this quite effectively but most probably don't anymore.

  • Brian Hogan // April 17, 2009 @ 03:30 PM

    You're 100% correct. There's simply no excuse not to use modules. Except that you just forgot.

    These libraries seem likely candidates for this week's "Works On My Computer" award.

  • Dan Pickett // April 17, 2009 @ 03:32 PM

    I'm somewhat in agreement, but full domain namespaces get so long and creates a lot of nesting.

    I've seen some gems/plugins use their company name as a namespace and for some reason I kind of take offense to it.

    Personally, I like intuitive namespaces based on the project name. IE, a creative project name like Feedzirra is unlikely to result in a collision if you use the project's name as the primary namespace.

    I think whatever the project name, it's important to always have everything nested in a namespace. I think the example you're mentioning above is problematic because extlib doesn't namespace at all. That is extremely lame. The chances of a collision are much higher with no namepsaces imo.

  • Daniel Higginbotham // May 10, 2009 @ 10:42 AM

    I came across this problem a little while ago and wrote a little tool the will namespace a constant and prevent this kind of collision: http://www.flyingmachinestudios.com/2009/05/10/aikidoka-prevents-ruby-namespace-collisions/

Leave a Comment