On Mar 23, 2006, at 1:01 PM, James Britt wrote:

> gwtmp01 / mac.com wrote:
>> On Mar 23, 2006, at 12:22 PM, James Britt wrote:
>>> That a given library makes deep changes to core objects or  
>>> behavior  should not be an issue if the nature and reasoning for  
>>> those  changes are made clear.
>> Until you need/want to use two such libraries.
>
> Can you give an example?

If you are asking for a specific example of a method redefinition  
from two
current and popular frameworks that are mutually incompatible, no.

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.

Rails defines Hash#to_options (a alias for Hash#symbolize_keys).  It  
just
so happens that in framework I'm working on I defined a method
Array#to_options to help parse a variable argument list.  Not a  
direct clash
but pretty close.

Rails redefines the backtick method (Kernel#`) to hide the Errno::ENOENT
exception.  The comment indicates that only Win32 systems raise the  
exception
but the redefinition will catch and suppress that exception.

I'm not trying to say that frameworks should never redefine or extend  
core
classes.   I was just trying to see if other people were thinking  
about this
and what conventions and/or language features might assist in avoiding
mutually incompatible changes/extensions to the core libraries.


Gary Wright