From: Sean Russell <ser@...>
Date: 2001-12-06T01:44:42+09:00
Subject: [ruby-talk:27563] Re: Package Naming

Jim Menard wrote:

> What I find tedious is that I am neither a company nor an organization. I
> don't own a domain name or company name. Therefore, I can't really create
> a "legit" package name. I haven't had anyone complain about "jimm.foo" but
> jimm.{com,net,org,info} are already taken.

That, and just using them.  Take, for example, a recent project I worked on 
for the US Forest Service.  Here's an example path:

        us.fed.fs.nris.tools.etools.client.wizards.ProjectBuilder

This was the common depth of a class, and all of those path elements were 
"required".  I found that this encouraged developers to stick everything 
into one package in an attempt to make thing a *little* easier, and they 
tend to block import packages:

  import us.fed.fs.nris.tools.etools.client.wizards.ProjectBuilder
  import us.fed.fs.nris.tools.etools.client.wizards.DatasetBuilder
  import us.fed.fs.nris.tools.etools.client.wizards.TableView

and so on, becomes:

  import us.fed.fs.nris.tools.etools.client.wizards.*

This wouldn't really affect Ruby much, but it is bothersome in Java.
When you have to deal with this package depth, paths are difficult to 
remember, files can be difficult to find, and you start sacrificing your 
own organization because it exacerbates the situation.

Even more distressing is when you have to use somebody else's package.  If 
you've done any serious Java programming, you may be able to identify that 
sense of relief when you find a software library that has a short, simple 
package name.  Java's package naming conventions do *not* encourage short, 
simple package names.

As I said, I don't have a better solution.  Scoped aliases may help; as 
somebody mentioned earlier, being able to do something like:

  module MyScope
    alias_package :some.really.long.and.annoying.package.name, :xml
  end

....

  import MyScope
  require xml.Document

  class Blah
    # ...
  end

would make things easier.  In any case, I recognize the *problem*, I just 
don't like the resulting difficulties imposed by the solution.

-- 
--- SER