Singleton class terminology

[Hal Fulton]

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

 

[ES]

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

 

[Michel Martens]

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.

 

[David A. Black]

Hi --

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.

It wasn't supposed to remind one of "idiom". It's a separate use of
the idio- prefix (as in idiolect, idiosyncrasy, etc.).

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]"?

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.

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.


David

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Singleton class terminology"

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

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

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

 

[David A. Black]

Hi --

On Mon, 9 May 2005, Hal Fulton wrote:

[...]

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]"?

Some more thoughts:

What I do like about the "class" in "singleton class" is that it fits
so beautifully, from the object-handling point of view, with the rest
of the design. By which I really mean that I would not want to see
some completely new category or concept introduced, cut adrift from
the basic language design and its familiar idioms, just for the sake
of not calling it something familiar, even if calling it that is a bit
of a stretch.

I'm concerned about a proliferation of concepts and terms: class,
module, new thing.... I'm not in agreement with Matju about unifying
classes and modules, but on the other side of the equation I think
having a completely separate concept to deal with the housing of
singleton methods and constants (and, presumably, new keywords
and syntax for getting access to them) would run a serious risk of
clutter.


David

 

[Austin Ziegler]

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.html#objects

 

[David A. Black]

Hi --

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

 

[Gavin Kistner]

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]

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

 

[Ryan Leavengood]

Hi --




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 came up with "shadow class", but I think David makes some good points.
Also looking at Matz's criteria from the other thread for a good name:

I'd like to emphasize the "per-object" attribute of the object.
Ideally, the term should be "xxxx class" where

* xxxx describe the class is per-object.
* xxxx is an adjective, or a noun that can be used like adjective.
* we can call methods now we call "singleton methods" as xxxx
methods for consistency.

* Shadows are usually associated with one object.
* Shadow is a noun, though I don't know if it could be used as an adjective.
* But "shadow methods" instead of "singleton methods" doesn't quite
sound right. Hmmm, but it might grow on me...

Still, is "singleton class" really that bad?

Ryan

 

[Christoph]

Some more thoughts:

What I do like about the "class" in "singleton class" is that it fits
so beautifully, from the object-handling point of view, with the rest
of the design. By which I really mean that I would not want to see
some completely new category or concept introduced, cut adrift from
the basic language design and its familiar idioms, just for the sake
of not calling it something familiar, even if calling it that is a bit
of a stretch.

Very, very nice point

I'm concerned about a proliferation of concepts and terms: class,
module, new thing.... I'm not in agreement with Matju about unifying
classes and modules, but on the other side of the equation I think
having a completely separate concept to deal with the housing of
singleton methods and constants (and, presumably, new keywords
and syntax for getting access to them) would run a serious risk of
clutter.

I am sort of neutral on Matju's unification - however if we must
have separate concepts I just don't see why the class Class (in its
current form) is a subclass of Module, besides implementation
convenience?

I’d rather subclass both from Object directly and stick the common
reflection methods in a separate Module e.g.

class Module < Object
include MethodKernel
end

class Class < Object
include MethodKernel
end

/Christoph

 

[Hal Fulton]

Hi --




It wasn't supposed to remind one of "idiom". It's a separate use of
the idio- prefix (as in idiolect, idiosyncrasy, etc.).

OK, I see. I didn't think of "idiosyncrasy," and I don't know
the word "idiolect." :/ In short, I have never known what
that prefix means.


Hal

 

[ES]

OK, I see. I didn't think of "idiosyncrasy," and I don't know
the word "idiolect." :/ In short, I have never known what
that prefix means.

There are two distinct connotations to that prefix which accounts for
the confusion: firstly, it is often vulgarly used to refer to language
(in English, that is; /idioma/, in Spanish, means language) but secondly
(and originally) it refers to something particular, specific or
unique--idiosyncracy can be explained as something that is only known
within its context.

David's suggestion is linguistically delicious in that the way
metaclasses
are handled in ruby is idiosyncratic to ruby as well as carrying the
hidden
inference to the peculiarity of a language and, indeed, *a* language in
general are exactly what this situation is about.

I nominate David for the Grand Equivoque of the Foxy Argotist Society.

Hal

E

 

[Martin DeMello]

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 in Ruby, a class is pretty much a place where method lookup is done,
is it not? Hence the whole class/type debate.

martin