From: Daniel Brockman <daniel@...>
Date: 2005-07-28T09:34:44+09:00
Subject: Re: What's so special about operators, built-in classes and modules?

"Ara.T.Howard" <Ara.T.Howard@noaa.gov> writes:

>>> the problem is a bit deeper than that and stem from the
>>> fact that including a module does not inject the
>>> included modules singleton methods into the 'includee'.
>>
>> Right, but to me that is just another reason to unify.
>> How is this inconsistency a feature?  Why is it not fixed?
>>
>> Does any code depend on the fact that including a module
>> does not pull in its singleton methods?
>
> i'd say __all__ code depends on that.  otherwise
>
>    module M
>      def self::new
>        raise
>      end
>    end
>    class C
>      include M
>    end
>
>    c = C::new

Surely you are not suggesting that all code defines
singleton ‘new’ methods on modules?

Considering that this doesn't work,

   class X
     def self.new
       raise
     end
   end

   class Y < X
   end

   x = X.new

why do you expect your example to work?

I don't get why Y's singleton class inherits from X's,
while C's *doesn't* inherit from M's.

> i'd imagine this is the (one of) reason(s) for the
> current behaviour.

Why are you defining M.new?  Do you have actual code that
does this?

>> Yes, I use similar hacks too.  But don't you agree that it
>> would be nicer if modules and classes were consistent in
>> this regard, rendering these hacks unnecessary?
>
> yes - i just am not seeing how it could be done in a way
> that preserved or added to current functionality and was
> simpler.

No, it would not be possible to retain full backwards
compatibility, but I cannot think of a real-world case in
which actual problems would result.

> inheritence needs to be addressed specifically for it to
> make sense.

Why do you say that?

>> How does this look?
>>
>>                  ‘foo’    “bar”
>
> like this
>
>    .[0m~@~Xfoo.[0m~0~X    .[0m~@~\bar.[0m~@~]

Out of curiosity, what mail reader do you use?

-- 
Daniel Brockman <daniel@brockman.se>