From: gwtmp01@...
Date: 2006-06-14T01:44:01+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?


On Jun 13, 2006, at 10:38 AM, Yukihiro Matsumoto wrote:
> I don't think I understand you.  Do you want to allow #include to
> include classes?  Without making it MI?  Hmm.

It isn't altogether obvious to me why a class passed to #include  
couldn't be interpreted as a module (since instances of Class are  
instances of Module via inheritance). That is to say the superclass  
ancestors a class should not be considered by #include but any  
included modules should be as well as any directly defined instance  
methods. To illustrate:

module M; end
class A; end
class B < A; end
class C < A; include M; end
class D
   include B
   include C
end

M.ancestors => [M]
A.ancestors => [A, Object, Kernel]
B.ancestors => [B, A, Object, Kernel]
C.ancestors => [C, M, A, Object, Kernel]
D.ancestors => [D, C, M, B, Object, Kernel]

In the last example, A isn't an ancestor because the superclass  
relationship is ignored by my fictitious 'include'.

While I think this behavior could be well-defined, I'm not sure the  
subtlety is worth it nor do I think it suggests any particular answer  
to the question of how singleton methods should be handled by  
#include or some companion method that has been discussed.  On that  
point I'm in Matz camp.  I don't see an inherent relationship between  
the instance methods of a module and the singleton methods of the  
module object. In particular situations I can see the relationship  
but it isn't always guaranteed to be there. Instance methods are the  
raison d'etre of modules but singleton methods may exist for any  
object whatsoever.  I'm not sure why they (singleton methods) should  
be considered by #include at all.

I'm not sure I understand why singleton methods are tucked away in a  
pseudo-class object since none of the Class instance methods (new,  
superclass, allocate) seem to be applicable.  The container for  
singleton methods seems much more like a module than a class to me.   
There is a relationship between the singleton classes of related  
parent/child classes but couldn't that be modeled as module  
inclusion?  I'm probably missing some subtlety.  I am often reminded  
of the maze in Adventure ("You are in a maze of twisty little  
passages, all alike") when I think about this stuff.

Gary Wright