Nat Pryce wrote:

> I think you misunderstood my point.  The physical location of a Java
> package
> is separate from its logical name.  

Yes, I did misunderstand you.  Sorry.

> qualified class name, or an SQL query into a database, or whatever.  For
> example, if I move a package from a directory in the classpath and instead
> store it in a JAR file, I don't have to change any of the client code,
> only the configuration of the JVM.

I've encountered problems with things stored in JAR files, BTW.  While it 
works pretty well most of the time, sometimes you encounter situations 
where the location of the class does make a difference, although you are 
correct when you say that the binding between package name and file 
location is loose.

> 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.

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.

--- SER