From: "David A. Black" <dblack@...>
Date: 2005-05-16T08:32:18+09:00
Subject: Re: infinite number of singleton_classes

Hi --

On Mon, 16 May 2005, Lionel Thiry wrote:

> 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?

It would only be consistent to forbid them if singleton classes
themselves cease to exist (in some future Ruby implementation).  As
long as objects have singleton classes, and as long as those classes
are objects, it's consistent for them, too, to have singleton classes.

The closest thing to a possible use I can think of is class methods
(including accessors) on a singleton class -- like this:

   obj = Object.new
   c = class << obj; self; end
   c.class_eval { class << self; attr_accessor :x; end }
   c.x = 123

etc.  But it's probably a bit of a stretch.  Still, I don't feel that
there's any reason for c (in that example) not to be allowed to create
class methods (i.e., singleton methods for itself).


David

-- 
David A. Black
dblack@wobblini.net