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)