Hi --

On Mon, 16 May 2005, Christoph wrote:

> David A. Black schrieb:
>
>> 
>> I'd rather just see the #inspect bug fixed :-)
>> 
>> I don't think having (class << Class; self; end) be the superclass of
>> these singletons is a problem.  At least, if one had a reason to want
>> to go higher than one level (for example, adding a class method to a
>> singleton class -- has anyone done that?), it wouldn't really matter
>> what the class's superclass was.
>
> If you are "singleton class" you only have to do house keeping for a one
> instance only. There is a potential benefit of inheriting house keeping 
> methods
> but this is broken if Klass is the superclass of all "higher order" singleton
> classes. If inheritance does not work any more "higher order" singleton 
> classes
> are pretty much fake "higher order" singleton classes.

Here's another interesting variant:

   Klass = class << Class; self; end
   def Klass.m; puts "here"; end

   class C; end
   class << C
     class << self
       p superclass == Klass   # true
       Klass.m                 # "here"
       m                       # NoMethodError
     end
   end

i.e, having Klass as your superclass does not give you access to
Klass's class methods.  I'm not sure whether I think this makes it
more consistent (explained in a moment) or whether it makes the whole
thing, as you say, kind of fake.

By "more consistent", I mean:

Having a subclass able to call its superclass's singleton (class)
methods is, as far as I know, the only case where one object can call
another's singleton methods.  This arrangement seems to disappear in
the case of singleton classes of singleton classes... but at least it
disappears consistently (i.e., even in the case of "Klass" above).

Or something.  In practical terms there's probably not much mileage to
be had out of these.


David

-- 
David A. Black
dblack / wobblini.net