Hi --

On Mon, 13 Sep 2004, Robert Klemme wrote:

> Originally I was going to argue that "virtual" is inappropriate because it
> was deceiving.  While thinking about this issue it occurred to me that
> "singleton classes" aka "virtual classes" share a property with C++'s
> "virtual classes": you cannot instantiate objects from them.

Actually if C++ has virtual classes, I think that's all the more
reason for Ruby not to call them that.  Any such point of contact
inevitably leads to misunderstanding and/or expectation (i.e., that
Ruby will be like the other language).  


> OTOH, you can have exactly one instance of this class, but this instance
> preceedes the class (i.e. first the instance is created and then - maybe -
> the class).  Strictly speaking, the instance is the factory for the
> class - not the other way round as it is normally.
> 
> <philosophical>I depends on everyones notion of "class" whether he or she
> thinks this no longer makes it a class.  Although in that case I'd be
> interested to learn a more appropriate name for this
> thing.</philosophical>
> 
> > [I wrote:]
> >
> > the whole per-object
> > behavior model of Ruby is based on the idea that every object has both
> > a class of origin and a class of its own where the definitions
> > exclusive to that object reside.  This isn't abnormal, nor an
> > aberration; it's the way the whole thing works.
> 
> Well, it's normal in Ruby.  But generally speaking the naive OO expert
> would expect either not to have singleton/virtual classes (SVC :-)) *or*
> have Object#class return the singleton class - if that would exist.  Note,
> I'm not advocating to change this in any way - in fact it's good the way
> it is.  I just try to uncover why SVC often create confusion.

"Naive OO expert" -- interesting :-)  "Normal in Ruby" is good enough
for me, since we're talking about Ruby.  Otherwise it becomes an
argument that there's an immutable/official OO model that languages
must not deviate from.  (I know you don't really think this -- I'm
just extrapolating from what you're saying.)

> The schizophrenic thing about SVC is, that instances change their class at
> most once without showing it to the outside world (i.e. #class still
> returns the original class).

I think we're looking at this backwards in this discussion.  We're
looking at it as:  Objects have this weird class-like thing, so what
is it?  I think it's better to look at it from the other end, like
this:  Objects in Ruby can have methods added to them on a per-object
basis.  That's a fundamental principle of Ruby (whether it is true of
other OO languages or not).  The way Matz has chosen to implement this
is by associating a second, dedicated class with each object.  That's
what this class actually *is* -- it's the fulfillment of that design,
not something growing off the design that has to be explained
separately.  

The details then fall into place.  The fact that the class doesn't
exist until it's needn't does not have to mean that there's anything
virtual about it -- it's just a matter of efficiency, and it's
transparent.  And it's a perfectly real class, because it fits the
definition of what a class can be in Ruby.  

Hmmm... "dedicated_class"... hmmm... :-)


David

-- 
David A. Black
dblack / wobblini.net