Are you confusing a class that has no instances (yet) with the class
returned by the expression (class <<obj; self; end) ?
I don’t think so. The expression you wrote is an example of what has
been called a singleton but, it has no methods at all (neither class nor
I don’t see anything particularly special or interesting about a class
with no instances (I think that is what you mean by a class
with ‘only class methods and class data’). Certainly that isn’t what
all the hubbub has been about regarding ‘meta/eigen/singleton/shadow’.
I got the impression from the other thread on this that this is what the
hubbub is about. Given a class that allows one instance to be
instantiated, some optional class data members, some instance data
members, and some class methods and instance methods and another class
that allows only class data and class methods, there is no difference
in essence. The argument was what to call the second sort of class.
So, in other words, the difference between these two classes is really
the fact that you can refer to some data in the first type as instance
data, but since there’s only one instance, that’s really no different
than class data (except for syntax of course). In essence, these two
types of classes are the same and therefore matz’s original corrected
term for the second type ‘singleton’ fits. But, it is easily confused
with the ‘true’ singleton which is an instance of the design pattern
singleton (and the first class described above).
However, to eliminate ambiguity between the two, we need a term for the
second type of class (which is called a ‘static class’ in c# or c++, but
can’t be in ruby because it is a dynamic language).
My proposal of simpleton is really arbitrary–either class could be
singleton and the other simpleton, but since more would have to be
changed to make the first type simpleton, i suggested the second. And,
however much dislike you have for ‘simpleton’ it is accepted as a
synonym for singleton.
I do understand of course, that enforcing such a subtle difference in
terminology is impossible and agree with the other posters that there is
most likely going to be umpteen different ways of referring to these
classes (and methods).
I should also put a disclaimer on everything I just said above which
could be totally off base: I’m coming from a ‘compiled’ bkg and this
commentary might not make sense in an interpreted world. I do want to
be corrected if I’m totally off-base with this, so please enlighten me.
Nevertheless, even my misunderstandings should prove useful to someone.