On Tuesday 19 April 2005 09:29 pm, David A. Black wrote:
> Although... here's something interesting:
>
[... elided IRB session that illustrates that singleton classes have no 
instances ...]

Wow ... I didn't see that coming.  That has implications for elsewhere in the 
thread discussing the Ruby object model diagram where everyone is drawing 
ASCII art with arrows labeled "instance-of".  All those diagrams are rendered 
invalid in one fell swoop.  Wow. (I notice that Matz's diagram in the RI docs 
does not explicitly label the horizontal arrows "instance-of" ).

So, what do we call the relationship between a class and its singleton class?  
"singleton-instance-of"?  Maybe. 

Given that the Forman/Danforth formal definition of a metaclass is "A 
metaclass is an object whose instances are classes", then the only 
Forman/Danforth metaclass in Ruby is the class Class.

Although, after rereading the first few chapters of the book, it is clear that 
the Class singleton classes fulfill a very similar role to the classical 
Forman/Danforth metaclasses.  One could argue that Forman's use of 
"instance-of" really maps to "singleton-instance-of" ... but at that point we 
are arguing definitions and it not worth pursuing.

> I guess being an instance_of something is a unique relationship (only
> one class-of-which-you-are-an-instance to a customer), and having a
> singleton class doesn't mean you're an instance of it.  That seems to
> reinforce the non-factory aspect of all singleton classes, in the
> sense that it disallows even the one "instance of" relationship that
> one might have expected them to claim to have.  (I expected it -- I
> think I once knew, but had forgotten about, the above behavior.)

It also makes the name "Singleton" class a little odd.  I thought it was 
because a singleton class could only have a single instance.  Now I find out 
it can't even have that.  Perhaps they should be Zeroton classes :)

> > Indeed, Class is the Metaclass from which all the singleton metaclasses
> > derive.
>
> And all other Class objects too.  

Only things (that would be called metaclasses if they could only have 
instances) are derived (i.e. inherit) from Class.  All other class objects 
are merely instances of Class.

> But then "[Mm]etaclass" becomes 
> really kind of overloaded -- in the sense that on the one hand it is a
> suitable term for Class (which is truly the thing that stamps out the
> cookie cutters themselves), while on the other hand it gets used as a
> term for something which is unequivocally *not* in the cookie-cutter,
> meta-cookie-cutter, or factory family at all.

The formal definition does not require metaclasses (or classes) to create 
instances ... only that they /have/ instances (which is you so clearly 
demonstrated singleton classes have no instances).  The factory aspect was 
entirely part of the analogy and not part of the formal definition.

-- 
-- Jim Weirich    jim / weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)