From: Mark Hahn <mchahn@...>
Date: 2001-12-06T03:28:25+09:00
Subject: [ruby-talk:27585] Re: Package Naming

The forest service must be a hotbed for beauracracy.  The only requirement
is that the dot-com name be used.  Thus all the length you are showing is
the fault of the organization, not the naming convention.

The names I have used over the years are like:

    com.foo.util.Sorting  or  com.foo.acctg.Billing

Your names could have easily been us.fed.fs.Sorting also.

----- Original Message -----
From: "Sean Russell" <ser@germane-software.com>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>; <undisclosed-recipients: ;>
Sent: Wednesday, December 05, 2001 8:44 AM
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
>