From: "David A. Black" <dblack@...>
Date: 2004-09-13T21:51:56+09:00
Subject: Re: Singleton method on object via define_method?

Hi --

On Mon, 13 Sep 2004, Gavin Sinclair wrote:

> > On Mon, 13 Sep 2004, Gavin Sinclair wrote:
> >
> >> D. A. Black wrote:
> >> > I think Matz is actually migrating from 'singleton class' to
> >> 'virtual class'.  I don't like that term very much (there's nothing
> >> really "virtual" about it; it's a real class, once it's created, and
> >> if it's not created, it's not even virtual), but it's probably a
> >> good idea to keep the terminology unified.
> >>
> >> Interesting.  "It's a real class, once it's created, ..."  On what
> >> grounds do you deem it to be a "real" class?
> >
> > irb(main):001:0> c = (class << ""; self; end)
> > => #<Class:#<String:0x402a8294>>
> > irb(main):002:0> c.class
> > => Class
> 
> >> And if there were such a thing as a "virtual class", what would it be?
> >
> > I have no idea.  The term doesn't evoke anything to me.
> 
> I don't know what a "virtual class" would be in real terms, but
> semantically, I'd say it's some kind of object benignly masqerading as a
> class.  Like a proxy object for a remote Froboz object might be said to
> masquerade as a Froboz.
> 
> So just because your object above tells the world it's a "Class", I'm not
> necessarily convinced.  I realise that, if this _is_ a benign deception,
> it's a deep one, because you'd expect the #class method to be truthful. 
> However, that's to be expected when we're talking about the deep internals
> of Ruby.
> 
> If the singleton class of an object is not treated exactly the same as a
> "normal" class in Ruby's implementation, then I think there's some
> justification for the word "virtual".

I think this introduces an unnecessary level of complexity.  You're
taking the long way around -- it's a Class object, but it's not a
class, but it acts like one, so we might as well say it is -- when in
fact it's simply a Class object.  There's nothing more or less
"normal" about it than about other Class objects; 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.  


David

-- 
David A. Black
dblack@wobblini.net