Asp Forum - Singleton class terminology

Hal E. Fulton

5/8/2005 8:04:00 PM

Just expressing my opinion here.

I don't like the term "idioclass" because "idio" doesn't
remind me of "idiom" at all, and even if it did, it would
be meaningless to me.

I don't mind the term "singleton class." I'm used to it.

If it must be changed, though, I question whether even the
word "class" is appropriate.

Consider the traditional meaning of "class" in OOP -- consider
the *reason* that word was chosen. A "class" is a category.
It is like a template that characterizes the members of that
category -- in real life, we expect the "class" of Ford automobiles
to have certain things in common, or there would be no reason to
"class" them (or categorize them) together.

But in that sense, a "singleton class" is not a class at all.
It is just a "place" where we store information on unique methods
and attributes and such. A class also has a "place" associated
with it -- whether you think of it as a place in memory, or in
the interpreter's code, or in the programmer's brain.

But the class and the "place where the class's stuff is stored"
are not really the same thing, are they? I submit they are not.

I further submit that what we call a "singleton class" is a
(or has a) "place" but isn't a class at all really; whereas a
real class IS a class and also has a "place" to store its stuff.

So we've been concentrating on changing the first word of the
phrase "singleton class." Could we perhaps change the second
word instead, making it a "singleton [whatsis]"?

Is my thinking here of any value at all?

Hal

15 Answers

ES

5/8/2005 8:15:00 PM

Le 8/5/2005, "Hal Fulton" <hal9000@hypermetrics.com> a écrit:

>Just expressing my opinion here.
>
>I don't like the term "idioclass" because "idio" doesn't
>remind me of "idiom" at all, and even if it did, it would
>be meaningless to me.
>
>I don't mind the term "singleton class." I'm used to it.
>
>If it must be changed, though, I question whether even the
>word "class" is appropriate.
>
>Consider the traditional meaning of "class" in OOP -- consider
>the *reason* that word was chosen. A "class" is a category.
>It is like a template that characterizes the members of that
>category -- in real life, we expect the "class" of Ford automobiles
>to have certain things in common, or there would be no reason to
>"class" them (or categorize them) together.
>
>But in that sense, a "singleton class" is not a class at all.
>It is just a "place" where we store information on unique methods
>and attributes and such. A class also has a "place" associated
>with it -- whether you think of it as a place in memory, or in
>the interpreter's code, or in the programmer's brain.
>
>But the class and the "place where the class's stuff is stored"
>are not really the same thing, are they? I submit they are not.
>
>I further submit that what we call a "singleton class" is a
>(or has a) "place" but isn't a class at all really; whereas a
>real class IS a class and also has a "place" to store its stuff.
>
>So we've been concentrating on changing the first word of the
>phrase "singleton class." Could we perhaps change the second
>word instead, making it a "singleton [whatsis]"?
>
>Is my thinking here of any value at all?

Yes, excellent question! I was thinking about just giving it
a nonsense name since there really is no direct correspondence
to any existing, if you will excuse me, idiom.

Could we call it #pouch? :)

>Hal

E

--
template<typename duck>
void quack(duck& d) { d.quack(); }

Michel Martens

5/8/2005 8:53:00 PM

On 5/8/05, Hal Fulton <hal9000@hypermetrics.com> wrote:
> But in that sense, a "singleton class" is not a class at all.
> It is just a "place" where we store information on unique methods
> and attributes and such.

You're right. I think the terminology for what we now call "singleton
class" should elide both terms and better reflect the fact that it's a
place with the characteristics you have just described.

Michel.

dblack

5/8/2005 9:12:00 PM

Yukihiro Matsumoto

5/8/2005 10:53:00 PM

Hi,

In message "Re: Singleton class terminology"
on Mon, 9 May 2005 06:12:19 +0900, "David A. Black" <dblack@wobblini.net> writes:

|Matz has also talked about the fact that the singleton class is really
|just one way to implement per-object modification. He'd mentioned a
|"class-like object" that might not actually be a class. Some
|questions arose in that context, like: would there be a class
|interface to it? what would class << obj; self; end give you? etc.

You can forget my words. If I adopt the new model,

class << obj; self; end

will always give you a "singleton class" (or whatever we name it).

matz.

Logan Capaldo

5/8/2005 11:18:00 PM

On 5/8/05, ES <ruby-ml@magical-cat.org> wrote:
>
> Le 8/5/2005, "Hal Fulton" <hal9000@hypermetrics.com> a écrit:
>
> >Just expressing my opinion here.
> >
> >I don't like the term "idioclass" because "idio" doesn't
> >remind me of "idiom" at all, and even if it did, it would
> >be meaningless to me.
> >
> >I don't mind the term "singleton class." I'm used to it.
> >
> >If it must be changed, though, I question whether even the
> >word "class" is appropriate.
> >
> >Consider the traditional meaning of "class" in OOP -- consider
> >the *reason* that word was chosen. A "class" is a category.
> >It is like a template that characterizes the members of that
> >category -- in real life, we expect the "class" of Ford automobiles
> >to have certain things in common, or there would be no reason to
> >"class" them (or categorize them) together.
> >
> >But in that sense, a "singleton class" is not a class at all.
> >It is just a "place" where we store information on unique methods
> >and attributes and such. A class also has a "place" associated
> >with it -- whether you think of it as a place in memory, or in
> >the interpreter's code, or in the programmer's brain.
> >
> >But the class and the "place where the class's stuff is stored"
> >are not really the same thing, are they? I submit they are not.
> >
> >I further submit that what we call a "singleton class" is a
> >(or has a) "place" but isn't a class at all really; whereas a
> >real class IS a class and also has a "place" to store its stuff.
> >
> >So we've been concentrating on changing the first word of the
> >phrase "singleton class." Could we perhaps change the second
> >word instead, making it a "singleton [whatsis]"?
> >
> >Is my thinking here of any value at all?
>
> Yes, excellent question! I was thinking about just giving it
> a nonsense name since there really is no direct correspondence
> to any existing, if you will excuse me, idiom.
>
> Could we call it #pouch? :)
>
> >Hal
>
> E
>
> --
> template<typename duck>
> void quack(duck& d) { d.quack(); }
>
>

Well this is a little long but how about "singleton method table"? (or
"solo method table" or "idio_method_table or "pouch method table" ? ;)
)

dblack

5/8/2005 11:22:00 PM

Austin Ziegler

5/8/2005 11:30:00 PM

On 5/8/05, Hal Fulton <hal9000@hypermetrics.com> wrote:
> Just expressing my opinion here.
>
> I don't like the term "idioclass" because "idio" doesn't
> remind me of "idiom" at all, and even if it did, it would
> be meaningless to me.
>
> I don't mind the term "singleton class." I'm used to it.
>
> If it must be changed, though, I question whether even the
> word "class" is appropriate.

Thank you, Hal. This is much the same though that I've been having,
although I must admit that I really liked one of the suggestions given
in the other thread. Combine these two points, and I think that we
have a winner.

First, for anyone who ever used OS/2, you may remember the WorkPlace
Shell (WPS)[1]. It was a fully OO desktop that allowed you to do quite
a bit. Instead of "shortcuts" on the desktop, you had shadows. In many
ways, the concept as OS/2 used it isn't 100% applicable (as it was
"just a pointer"), but let's think about the term for a moment.
Someone suggested a shadow class. This is appropriate, to a degree,
because the "singleton class" shadows the object. But that disconnect
suggests the answer:

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?

-austin
[1] http://eepjm.newcastle.edu.au/os2/concepts.ht...
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca

dblack

5/8/2005 11:58:00 PM

Gavin Kistner

5/9/2005 12:16:00 AM

On May 8, 2005, at 5:57 PM, David A. Black wrote:
> 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.

I like it for sort of the same reason - the instance has a 'shadow'
of itself. Like the shadowed password file. It is part of itself, and
yet it is not.

That a shadow is insubstantial is also beneficial to the mental
model, as IIRC a 'singleton class' is sort of empty/non-existent
until asked for and filled out.

Shadow (be it 'shadow class' or 'shadow object') is the term which
best seems to be clear of collision confusion (unlike 'singleton' or
'abstract' or 'instance') and yet still (IMO) carry a bit of the
mental model along with it.

--
(-, /\ \/ / /\/

Christoph R.

5/9/2005 12:32:00 AM

David A. Black schrieb:

>
> There was a brief flurry of discussion of having it be a singleton
> module, which I actually think is potentially good. I can't remember
> which of these threads it was on... but searching for "singleton
> module" will probably unearth it.

You are surely aware that we already have a module called Singleton
(sort of implementing the OO variant of a Singleton). Since the potential
ambiguities between the OO version and Ruby's use of the term "singleton",
is the whole unholy raison d'etre for this gigantic never ending singleton,
meta, whatever class threads, you'd be open the flood gate threads about
the difference between ?a singleton module" and "the singleton module" if
you start calling non OO "singleton classes" "singleton module".

I am particularly looking forward for discussions about the?singleton
module"
of an OO-singleton class and the "singleton module" of the (OO) Singleton
module:-)

>
> Matz has also talked about the fact that the singleton class is really
> just one way to implement per-object modification. He'd mentioned a
> "class-like object" that might not actually be a class. Some
> questions arose in that context, like: would there be a class
> interface to it? what would class << obj; self; end give you? etc.

Of course you and Hal open up a serious issue if the class
of what we currently call "singleton class" really should
be a class, after all - that if
--
p class << obj; self end.class == Class
---
should return true,

If I understand you correctly you are sort of suggesting that we'll get
p class << obj; self end.class == Module # true ??
As a variant we could subclass Module as in
---
class VirtualMetaWhateverModule < Module
end
class << obj; self end.class == VirtualMetaWhateverModule # true
---

I felt for a long time that the many tests for FL_SINGLETON flags in
Ruby?s source code could be simplified by sub classing from class,
e.g.
--
class MetaClass < Class; end
# that?s is
p class << obj; self end.class == MetaClass # true
---

Since this is fairly obvious I am sure that Matz must have already
rejected this in his mind, however I must confess that I secretly wish
that Matz would seriously consider tinkering with the "root" of Ruby?s
Object hierarchy for Ride and instead of (only) tinkering with names
instead (this root top is important and quite possibly improvable
IMO).
As thing are, I hope Matz will stick with singleton class/methods or
change to "individual class/modules" and we can all move on ...

/Christoph

>
>
> David
>

comp.lang.ruby

Singleton class terminology

Hal E. Fulton

ES

Michel Martens

dblack

Yukihiro Matsumoto

Logan Capaldo

dblack

Austin Ziegler

dblack

Gavin Kistner

Christoph R.

x Login to ForumsZone