From: "Sean Russell" <ser / germane-software.com>
> > Ruby on the other hand exposes *both* the logical name of a
package/class
> > *and* the physical location in which the Ruby code defining that class
is
> > stored.  If I change the way I've organized my files I do have to change
> > client code.  This is an unavoidable artifact of Ruby's dynamic nature.
> > However, it does mean that clients of a class are more tightly coupled
in
> > Ruby than in Java, because they rely on two unrelated details -- the
> > logical name of the class and the physical location of the definition of
> > that class.
>
> I don't entirely understand this.
>
> In Java, if a class is foo.bar.cl, you still at some point have to have
the
> files in a directory structure foo/bar/cl.class, even if it is in a JAR
> file.  I believe this is more rigid than Ruby, where module Foo::Bar::Cl
> doesn't at all need to be in Foo/Bar/Cl.rb.  Your requires do bind tightly
> to the filesystem layout, but no more so than in Java.  With 'require
> "foo/bar/cl"', foo/bar/cl.rb can be anywhere in the load path, same as
with
> Java, and, just like Java's classpath, the load path can and does include
> any number of paths.

In Ruby, if I want to load a class Foo::Bar::SomeClass, I have to both
require the file that the class is packaged in, *and* import the module that
it is defined in.  In Java, I just import the module and the class loader
locates the file and loads the class.  How classes are organised as files or
other storage media is not exposed in client code.

A Java class loader has complete freedom to translate a fully specified
class name (e.g. including the package prefix) into whatever storage
location it wants.   The implementation of the system class loader in Sun's
JDK translates each class name into a ".class" file in a directory and then
searches for that file in the class path.  However, the implementation of
that class loader is *not* part of the language definition; rather it is
part of the standard library.  It is trivial to replace the system class
loader to load class files from somewhere else -- from files named like
"foo.bar.cl.class" for example.

However, that is an orthogonal issue.  The main advantage Java's class
loader has over Ruby's require statement is that it reduces coupling between
client code and *how* you have decided to package modules in physical
storage. If I move a Java class from one JAR file to another, I don't have
to change any client code.  However, if I move a Ruby class definition from
one .rb file to another, I have to change all client code that uses that
class. Therefore Ruby couples client code more tightly to the modules that
it uses than does Java.

> Now, if you are suggesting that you can rewrite a class loader to look for
> foo.bar.cl anywhere, without the associated filesystem path dependency,
> then you may be correct; however, I'd propose that you can do the same
> thing by overloading Ruby's "require" to do the same thing.

Yes, you could.  That doesn't help reduce the coupling caused by depending
on both the class name *and* the physical storage though.

Cheers,
            Nat.