From: Robert Klemme <bob.news@...>
Date: 2004-09-14T17:34:54+09:00
Subject: Re: Singleton method on object via define_method?


"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0409130856080.26699-100000@wobblini...
> 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 :-)

Isn't it? :-)

>  "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.)

Well, yes, the extrapolation was correct.  Although I couldn't agree more,
that there is no such thing as a commonly agreed model of OO, I'd say
singleton classes the way they are in Ruby are not part of it. :-)

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

While that's certainly true, we're (I am) here trying to grasp the nature
of these things to come up with a more appropriate name.  At least that's
my understanding of the thread.

> 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

.... but it might be a good reason to call it "virtual": it simply doesn't
exist the whole time. :-)  OTOH, you can't tell from the outside - it's
there when you need it - lazyly initialized...  ("lazy_class"? Oh no...)

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

.... apart from the instance creation.

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

How about "instance_class"?

Hmm...

    robert