From: Lionel Thiry <lthiryidontwantspam@...>
Date: 2005-05-16T08:20:30+09:00
Subject: Re: infinite number of singleton_classes

David A. Black a �crit :
> Hi --
> 
> On Sun, 15 May 2005, Lionel Thiry wrote:
> 
>> Hello!
>>
>> ----8<----
>> a = Object.new
>>
>> b = class << a
>> class << self
>>  class << self
>>   class << self
>>    # "class << self".times(n)
>>     self
>>    # "end".times(n)
>>   end
>>  end
>> end
>> end
>> # => #<Class:#<Class:#<Class:#<Class:#<Object:0x2aa8348>>>>>
>> ----8<----
>>
>> How many levels can we reach? It seems there is no limit.
>>
>> I suppose those singleton_class exists only when needed? Otherwise, I
>> really
>> wonder where does ruby hide all those singleton_classes...
>>
>> But, sincerely, is it needed to have the singleton_class of a
>> singleton_class?
>> Isn't it a non-sense? Shouldn't this raise an error?
> 
> 
> [...]
> 
>> What do you think of it? Isn't it worth an RCR?
> 
> 
> No; it's just a consequence of the underlying design principles.  Yes,
> there are a few objects that can't have a singleton class (Fixnums and
> Symbols are the ones I can think of).  But Class objects can, and
> singleton classes are Class objects.  So you'd be asking for
> special-case treatment for a subset of classes.
> 
> It would be a bit like saying:  Surely no one will ever use a
> singleton class as a hash key, so let's remove the #hash method from
> it.  There's just no reason to constrain the language and its usage
> that way.
> 
> Also, I don't see any harm or danger here.  I suppose one could
> accidentally write a loop that kept creating singleton classes, but
> one could also write a loop that kept creating *non*-singleton classes
> -- or arrays, or hashes, or MyClass objects, and so on.
> 

Well, I had something in mind when I wrote this... and it was not "Surely no one
will ever use this feature, then let's remove it". It was something more subtle.

I may be wrong in my interpretation, but I remember that Matz expected some
freedom of implementation of singleton method mechanism. Present mechanism is
that singleton methods are hold in a singleton class, which happens to be an
object instance of the class Class. But this may change in future version of
ruby. For example, singleton "classes" could not be a class anymore, or it could
even not be a normal object anymore. It could be anything, whatever please Matz.

Then, giving that fact as true, for the sake of future ruby versions, wouldn't
it be more consistent to forbid singleton class of singleton class?

I may admit that the such said "sake of future ruby versions" may need some
other marginal never truly used features be forbidden either. I don't know, I'm
not sure of anything.

And, please note this: I agree with you. There is nothing wrong or harmfull in
the current behavior, while looking from the point of view of a ruby user. But I
think it may be different from the point of view of a language designer and I
like to take count of it.

-- 
Lionel Thiry

Personal website: http://users.skynet.be/lthiry/