Nat Pryce wrote:

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

I'm sorry?  Why would the client ever care about the deployment??  The 
clients run 'ruby install.rb' and then follow the require instructions.  
Java people make sure a jar file is in the classpath, and hope that they 
can keep track of where all of the jars are, and which version of the jar 
they have installed... and follow the import instructions.  I don't see how 
the deployment has anything to do with this.  In any case, I have more 
trouble managing third party Jar files than I have ever had managing third 
party Ruby libraries.  That isn't, BTW, an endorsement of Ruby's library 
management system, which is much too similar to Perl's to make me 
comfortable.  I almost never use non-trivial Perl applications because of 
the difficulty of managing third-party libraries, and while Ruby is 
enjoying good times right now, I see Perl's problems in Ruby's future.

> In Java you can move classes between JAR files without changing client

And this happens... how often?  Never?

I've never moved a class from one jar to another without having to change 
the package name.  If I move something from client.jar to common.jar, I'm 
also invariably changing includes from *.client to *.common.

> code. In Ruby you have to change require statements in client code if you
> move a class from one Ruby file to another.

Same with Java.  It is *much*, *much* more common for people to have to 
change the package names than it is for them to move classes from one Jar 
to another.

Help me out... can you give me an example of requiring moving a class from 
one jar to another that doesn't also involve a package name change?

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

Damnum absque iniuria.  Theoretical difficulties never encountered in real 
life are irrelevant.  Mostly.  I mean, I really don't see the point in 
complaining about this, since... well... what difference does it make?

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

Naw, I still see the word "Ruby" in there.

-- 
--- SER