From: "Sean Russell" <ser / germane-software.com>
> Nat Pryce wrote:
> > 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.
>
> Ah.  I see.  I think this is an unfair comparison.  How often do you
define
> multiple classes in one source file in Java?  Most people do it very
> rarely.  Ruby makes it easier to put multiple classes in a single file,
but
> if you're going to compare the systems, you should use the same basic
> organizational model.

It is a completely fair comparison, and has nothing to do with defining
multiple Java classes in a single Java source file.  This is about packaging
code for *deployment*.

In Java you deploy multiple (compiled) classes in single JAR files.  In Ruby
you deploy multiple classes in single Ruby source files.

In Java you can move classes between JAR files without changing client code.
In Ruby you have to change require statements in client code if you move a
class from one Ruby file to another.

Therefore Ruby couples client code to both the *logical* name of the classe
and the *location* of the deployment unit.  Java only couples client code to
the *logical* name of the class; the mapping to *location*  of the
deployment unit is a configuration detail that is hidden from the client
code.

Of course, Ruby is much more dynamic than Java (hence the additional
coupling).  This allows you to, for example, define a single class in
*multiple* Ruby files.  E.g. the statement "require 'ftools'" extends the
built in File class with additional methods.

Anyway, this discussion has mostly moved off topic, so I'll stop discussing
it on the ruby-talk list now...

Cheers,
            Nat.