Unified Type/class

[Pedro Rodriguez]

"Alex Martelli" <aleax at aleax.it> wrote:

> "Vincent Foley" <vince at news.videotron.ca> wrote in message
> news:Olg48.7695$7U5.551678 at weber.videotron.net...
>> I'm no expert on the Python language, or OO programming, but it's
>> possible in the language Ruby <www.ruby-lang.org> to add new methods to
>> existing classes.  For example, it is possible to had a rot13 method to
>> the String class.  Is this one of the things this Python type and class
>> unification renders possible?
> 
> Python allows a class to forbid addition of attributes to its instances.
> 
> The classes in turn are instances of a metaclass.  Python allows a
> metaclass to forbid addition of attributes to its instances (classes).
> 
> The metaclass of type str uses this ability and thus stops you from
> adding methods to the str class object.  (The same metaclass, when used
> for your own class statements, does allow such additions).
> 
> You may code your own metaclasses as you wish, but (in the general case)
> may not be able to switch a class's metaclass on the fly.
> 
> 
> Alex
> 
> 
> 

Check Guido's reason in 'descrintro' document (search for the phrase
containing 'no-no' at the end of 'Introspecting instances of built-in
types').

A question : how does Ruby address the following situation :
- there is a library L1 that adds a rot13() method to 'str' class (no args)
- there is another library L2 that adds rot13(someargs) method to 'str'
- each library comes from different and not related developers
- rot13() is not the reason why somebody will use L1 or L2

What will happen if I decide to use both libraries in an application ?
Is there a name clash, or a risk of messing both rot13 implementation ?

It reminds me (in some way) of diamond problem with multiple inheritance :
        CORE.
       /  |  \
      L1  |  L2
       \  |  /
        Appl.

CORE language provides some features, if anyone (L1, L2) are allowed to
alter those features, what should Appl. developper expect from the CORE.
Even adding a method could be a problem. I consider that, when requiring
to augment CORE features, it should be dealt as part of the library
framework and not by altering the CORE directly.

Regards,
-- 

Pedro