Gary Wright wrote:
> But here is a examples that make me wonder:
> Rails redefines Module#const_missing to auto load Rails controllers.
> 
> It seems to me that playing around with const_missing by more than one
> library would be problematic.  I'm not saying that it can't be done but
> that all implementations would have to respect some set of conventions.

An actual conflict with const_missing has already occurred.  I added a 
const_missing handler to Rake when I cleaned up the global namespace and 
moved some constants into the Rake namespace.  But I wanted people using 
constants in the top level namespace to get a deprectated message with 
instructions regarding what they had to change to work with the new Rake 
command.

I carefully wrote the handler to complain only about the handful of 
constants I moved, anything else would be forwarded to the previous 
const_missing handler.

Well, that worked great until the new rake was used in a Rails project. 
At the time, rails didn't forward chain const_missing requests, so 
things got kinda messed up.  IIRC, Jamis was one the problem as soon as 
I mentioned something (or maybe he told me ... I don't remember), and a 
fix was commited almost immediately.

Today, both Rake and Rails use a const_missing handler without 
interfering with each other.

The moral of the story is: You need to be careful in creating libraries 
that touch the "public" portions of Ruby.  I've been meaning to write 
down a few guidelines that I tend to follow, but haven't had time yet. 
I think the time is ripe for someone to codify a "How to play together 
nicely in Ruby" set of guidelines.

--
-- Jim Weirich


-- 
Posted via http://www.ruby-forum.com/.