From: "David A. Black" Date: 2009-11-18T22:22:28+09:00 Subject: Re: Any official name for Ruby's class which makes "class me Hi -- On Wed, 18 Nov 2009, Marnen Laibow-Koser wrote: > Rick Denatale wrote: >> On Tue, Nov 17, 2009 at 10:12 AM, Marnen Laibow-Koser >> wrote: >>> >>> But I think that is what is meant. ???How else does the diagram on that >>> page make sense? ???Every class has an associated metaclass of the same >>> name in that diagram. ???What is that if not the Class object? >>> >>>> That would make "metaclass" a synonym for "class", which wouldn't make >>>> sense. >>> >>> I think that "metaclass" is here a synonym for the Class object, as >>> opposed to the class declaratio or anything else. >> >> Then how does the sentence before the sentence you originally quoted >> make sense: >> >> In the diagram that follows, the vertical arrows represent >> inheritance, and the parentheses meta-classes. All metaclasses are >> instances of the class `Class???. >> >> There are lots of parenthesized 'metaclasses' and none ARE Class. > > I took the parenthesized items on the diagram to be the actual Class > objects, while the nonparenthesized items were the classes that most > programmers are more likely to interact with. > > It's strange, I know, but I really can't think of an interpretation that > makes more sense. They're all instances of Class, and thus all actual Class objects. Every Ruby object has what I sometimes call a "birth" class (String for "abc", Class for Object, etc.), and then in addition, every object (almost) may, optionally, have a singleton class. The singleton class, which is anonymous, exists for the purpose of serving as the repository of singleton methods for this object, and to provide a node on the method lookup path where modules can be included for this object only. It's kind of a nature/nurture thing. The original nature of the object is represented by its "birth" class. The nurture of the object -- the processes by which it branches away from what would otherwise have been the entirety of its identity -- is carried out via its singleton class. (Of course, this analogy doesn't take into account the fact that the "birth" class can change dynamically. But it's a good start.) Matz has always emphasized that the main thing here is the individuation and dynamism of objects, and that the two-class model is just a way to implement that dynamism. He's even discussed in the past the possibility of doing it some other way in the future, though my recent understanding is that the two-class way is probably here to stay, at least for the foreseeable future. And it works really well, partly because you get the same interface to the singleton class that you do to the "birth" class (the class keyword). David -- THE COMPLEAT RUBYIST, Ruby training with Black/Brown/McAnally! January 22-23, Tampa, Florida Info and registration at http://www.thecompleatrubyist.com -------------------------------------- My new job: http://tinyurl.com/yfpn9hz