From: "David A. Black" <dblack@...>
Date: 2005-05-09T08:57:43+09:00
Subject: Re: Singleton class terminology

Hi --

On Mon, 9 May 2005, Austin Ziegler wrote:

> What we now call the "singleton class" is really a "shadow object".
> Indeed, we could simply get away with calling it the object's #shadow
> (#__shadow__ for safety purposes). Similarly, we could have #shadow?
> (or #is_shadow?) to satisfy Ara's needs.
>
> What do you think?

I don't like "shadow" for this.  Shadow suggests, to me, a light
source, an object, and a shadow.  I can't see how that maps onto this.
It just feels all wrong spatially.

Also, a shadow is, so to speak, caused by the body or object.  Again,
I just don't see what is shadow-like, in that sense, about wherever an
object's singleton methods are kept.  There's no cause/effect
scenario.  If anything, the "shadow" is the indirect cause of the
composition of the object, not the other way around, and even that is
a big stretch.

In general, a shadow is also insubstantial, so that "shadow object" is
a kind of oxymoron.  Sometimes it's used figuratively, like a
detective "shadowing" someone.  But I don't think the singleton
storage area "shadows" the object, in that sense.  Nor is it the
object's shadow.  That suggests congruence and completely coordinated
behavior -- but actually, the singleton side of an object's behavior
is just part of the story.  The singleton class does not show us the
whole shape and motion of the object, only part of it.  So I would not
think of it as being in any sense a "shadow" of an object.

I can imagine myself, in trying to explain this, saying, "What's
called the object's shadow is best thought of as a kind of 'singleton
class'...."


David

-- 
David A. Black
dblack@wobblini.net