From: Sean Russell <ser@...>
Date: 2001-12-06T13:56:59+09:00
Subject: [ruby-talk:27620] Re: Package Naming

Robert Feldt wrote:

> I think we should go with a "logical" module hierarchy. IMHO, its better
> than the java convention since I'd like my code to talk about what it does
> (and I find text/markup/xml more informative than
> com/foo/bar/SUPERDUPERXML) and not about organizations etc.

I agree.  I think we can avoid the vast majority of naming conflicts with 
this, although I still believe we need the package name in there somewhere. 
For example, you have four XML parsers for Ruby already.  It may be an 
extreme example, but a non-theoretical example of needing all three loaded 
at one time are the comparison programs (I have one testing speed and 
there's another testing OASIS conformance).  Something like:

        text/markup/xml/rexml
        text/markup/xml/nqxml
        text/markup/xml/xmlparser

although, I have to admit, I'm already getting tired of the depth of 
references.  I will violently oppose anything that will require me to write:

        doc = text::markup::xml::rexml::Document.new( file )

if I don't want to include() the package.

> Ok, but IMHO clarity wins in the long run over brevity...

Ease of use wins over clarity.  Well, maybe not absolutely, but consider: 
Ruby does a good job of removing many common obsticles of programming; we 
don't want to start inserting obsticles back into the language, or else 
Ruby will end up like every other unweildy programming language.

>> pain to refactor, and moving things around ends up affecting a lot of
>> source code.  Also, until Matz gets

Hear, hear.  Good lord, but just moving a file from one package to another 
in Java can be a real nightmare.  I'd really rather not see this happen to 
Ruby.  Maybe we can solve these problems with scoping, rather than 
packages.

>> So, what do folks think? Should we start implementing module
>> hierarchies, or is there a better way. Should RAA.succ enforce all
>> this?

I'd rather spend more time looking at the problem and solutions, or, at 
least, have the solutions not be enforced until we have studied the problem 
much more.  I'm very fearful that a lot of damage could be done by rushing 
into a solution which sounds good on paper, but which has proven to be a 
hinderance to development in other languages.

-- 
--- SER