> 
> 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 
instance).

> 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. 
:)

--J

-- 
Posted via http://www.ruby-forum.com/.