From: Rich Kilmer <rich@...>
Date: 2001-12-06T15:48:40+09:00
Subject: [ruby-talk:27648] Re: Package Naming

> -----Original Message-----
> From: Nat Pryce [mailto:nat.pryce@b13media.com]
> Sent: Thursday, December 06, 2001 12:31 AM
> To: ruby-talk ML
> Subject: [ruby-talk:27628] Re: Package Naming
> 
> 
> 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.

But they still have to know the relative organization which IS a path (in the fsys, jar or url).  If you change the directory structure in the relative paths you DO have to refactor.

In Ruby the LOAD_PATH is very similar to the CLASSPATH of Java, with files loaded relative to those elements within the path. Its just (like yoo indicate below) the namespace loaded by those files in Ruby is not the same as the relative path (like in Java).

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

Right...which is a benefit so we can have the (relative) file strucure based on creator (com/infoether/jabber4r) and the namespace on a logical structure (Net::IM::Jabber). I know another file could overwrite the Net::IM::Jabber namespace.  The only way to prevent this is for the Jabber module to call #freeze after it is loaded (which sucks a bit).

I do understand your points though.

BTW:  I've (kinda) solved this problem myself when I wanted to create a sandbox to load a Ruby file where I did not want it to 'stomp' on core namespaces like this:

file_a.rb:

module A
 module B
   eval(File.read('../sandbox/file_b.rb'))
 end
end

../sandbox/file_b.rb:

module C
 module D
 end
end

(where ../sandbox is NOT in the LOAD_PATH so cannot be require'd)

the Modules are then:

A
A::B
A::B::C
A::B::C::D

-Rich