From: ES <ruby-ml@...>
Date: 2005-05-17T05:01:28+09:00
Subject: Re: infinite number of singleton_classes


Le 16/5/2005, "Ara.T.Howard@noaa.gov" <Ara.T.Howard@noaa.gov> a �crit:
>On Tue, 17 May 2005, Christoph wrote:
>
>> Ara.T.Howard@noaa.gov schrieb:
>>
>>>>  misunderstood something once again?
>>>
>>>
>>> well - sorta ;-)
>>>
>>> i only meant to say that the behaviour is consistent and, although
>>> there is no
>>> regular ruby idiom that makes use of it now, there may well be in the
>>> future.
>>
>> Actually the behavior is not consistent  - assuming the definition
>> ----
>> public # create meta objects
>> def m(height =1)
>>    height.zero? ? self  :   class << self; self end.m(height -1)
>> end
>> ----
>>
>> and the natural inheritance assumption, that the class relation
>>
>> X < Y         # true, implies
>> X.m < Y.m # true
>
>here we depart.  i don't assume this because X's singleton class is just that
>: a singleton (eg. one) class with no relation to that of Y's.  i think of as
>in
>
>   class Clothes
>   end
>
>   class Shirts < Clothes
>   end
>
>   class Pants < Clothes
>   end
>
>   class TShirts < Shirts
>   end
>
>now, obviously, we have something of a hierarchy described in 'is-a' terms:
>TShirt 'is-a' Shirt, etc.
>
>now we thow in a __separate__ hierarchy : Pockets.  so
>
>   class Pocket
>   end
>
>Pockets, obviously, being where classes store their personal (singleton)
>stuff.  ;-)
>
>now we have
>
>   class Clothes
>     class Pocket < ::Pocket
>     end
>   end
>
>   class Shirts
>     class Pocket < ::Pocket
>     end
>   end
>
>now this is a 'has-a' relationship: a Pants 'has-a' Pocket class
>(Pants::Pocket) and Shirt 'has-a' Pocket class (Shirt::Pocket).  there __is__
>a subtle 'is-a' relationshiop between pocket classes : a Shirt::Pocket 'is-a'
>::Pocket and a Pant::Pocket 'is-a' Pocket.  however we do not (necessarily)
>have : Shirt::Pocket 'is-a' Pants::Pocket.

No, that would imply Shirt::Pocket < Pants::Pocket. However, I
think it is profoundly faulty to imply there is not a significant
relationship between the two. Both children should share the traits
of their parent but not those of their siblings.

>in this case the Pocket class(es) are singleton classes.  all classes have one
>that descends from a parent singleton class(es).  this is a hierarchy that is
>related to, but separate and parallel from, the hierachy of any classes which
>may themselves have some arbitrary inheritence relationship.
>
>so, for me, it is consistent.
>
>consider the more generic case and it makes much more sense
>
>   a = []
>
>   class << a
>     def foo; 42; end
>   end
>
>   a2 = []
>
>   class << a2
>     def bar; 'forty-two'; end
>   end
>
>surely the search path for
>
>   a.bar
>
>should not look into a2's singleton class for it and, conversely,
>
>   a2.foo
>
>should not look into a's singleton class.  both methods should raise a
>NoMethodError.  why?  because there exists no relationship between the
>singleton classes of two instances of a class.  in this case the instances are
>of class Array, but remember that ruby classes are just instances of class
>Class so the same holds true.

Your analysis is correct but the analogy is not quite, er
analogous. To make it similar, each singleton (or pouch)
would be a subclass of Pocket here. Therefore, while the
methods defined in each of them have no relevance to the
other (siblings' traits are not inherited), they _should_
share the methods from any common ancestors.

So, if child_one.pouch and child_two.pouch are subclasses
of parent.pouch, they should both share any methods in
parent.pouch but not (necessarily) eachother.

>so the only reason that
>
>   class C; end
>   class B < C; end
>
>   class << C
>     def foo; 42; end
>   end
>   class << B
>     def bar; 'forty-two'; end
>   end
>
>permits
>
>   B.foo
>
>is __not__ because B.singleton_class < C.singleton_class.  rather it is
>because the search path for a method is, naturally, up the ancestor list
>hierarchy and, at each step along the way, each class additionally looks
>'sideways' into it's singleton_class (it's pocket) but not into the
>singleton_class of any other classes since, by definition, those classes
>belong only to the object that created them - it would be like looking into
>someone else's pockets ;-)

This is certainly true.

>cheers.
>
>-a

E

--
template<typename duck>
void quack(duck& d) { d.quack(); }