In both Ruby *and* Java, renaming a package requires changing the clients of
that package.

Java doesn't have parallel package and file organisation like Ruby.  Or
rather, Java doesn't expose the organisation of class files at the language
level -- instead it encapsulates it into class loaders that look up class
files from the class-path, JAR files, web sites, etc.  Java programmers only
need know about the logical package organisation, not the organisation of
the storage of those packages.  Therefore, in Java, moving a class between
directories or machines, or even organisations, doesn't require any
refactoring.  It just requires some configuration changes.

In Ruby, a programmer must know both the logical organisation of packages
*and* the name of the physical unit in which those packages are defined.
Because of the dynamic nature of Ruby, there is no way to hide the file
organisation from the language level.  For example, requiring one Ruby file
can change a class defined in another Ruby file.

Cheers,
            Nat.

________________________________
Dr. Nathaniel Pryce
B13media Ltd.
40-41 Whiskin St, London, EC1R 0BP, UK
http://www.b13media.com

XP Day, London, UK. 15th December 2001. http://xpday.xpdeveloper.com/

----- Original Message -----
From: "Rich Kilmer" <rich / infoether.com>
Well...the problem with Java is that the packages and paths are the same.
So my package imports are tied to my path.  Also, wherever I use a class I
have to import it because of strong typing.  This is not the same for Ruby.
I can 'require' one place for the whole Ruby session and the modules/classes
are now in the ObjectSpace.  So using files that match the domain
(com/domain/library) for a 'require' does not introduce the same impact on
refactoring in Ruby in the event that the domain/library (file path) needs
to shift.  Having to update a single require is cake compared to Java where
I have to update all the import statements...everywhere I use
them...ahhh...man I am glad to be coding in Ruby!

-Rich