From: "David A. Black" <dblack@...>
Date: 2005-05-16T11:02:37+09:00
Subject: Re: Bug printing classes - Re: infinite number of singleton_classes

Hi --

On Mon, 16 May 2005, Christoph wrote:

> David A. Black schrieb:
>
>> 
>> I'm just not ready for:
>> 
>>   class << obj; def self.x; end; end
>> 
>> to throw an error.  It just seems like taking away too much
>> class-ness -- though obviously if the class interface to object
>> singleton behavior disappears entirely, that won't be an issue.
>
> I was kind of proposing to throw an error at the next level
>
> class << obj; class << self def self.x; end; end; end
>
> Disallowing the formation of  the "singleton singleton class" of
> any type of class including "singleton classes" - this would
> effectively kill Ara's usage example

You're three-deep here, though.  I thought you meant to disallow
two-deep (singleton class of a singleton class).  (In my example I'm
assuming that "def self.x" puts x into the singleton class of self,
which is itself the singleton class of obj.)

>>> As a side note the class Klass lends itself naturally as the mother of all
>>> singleton classes - i.e. "pouch == Klass" - a problem with this idea is 
>>> that
>>> we currently have Class <  Module < Object.
>> 
>> 
>> I'm not sure what you mean.  If every object's "pouch" is Klass, it
>> will get very crowded....  But I think I'm misunderstanding.
>
> Singleton classes could be instances of Klass, essentially Klass would be a 
> subclass
> and "singleton class" of Class at the same time. This is similar (kind of the 
> higher order
> version of) of Matju's  proposed identification.
>
> class << Object; self end == Class

It then becomes a little confusing to call them "classes", since
they're instances of something other than Class.  And it raises the
whole subclassing Class problem....


David

-- 
David A. Black
dblack@wobblini.net