From: Gary Wright <gwtmp01@...>
Date: 2008-02-17T06:05:29+09:00
Subject: Re: object specific methods and id


On Feb 16, 2008, at 3:30 PM, UpsNDowns wrote:
> Alas, my problem now is, that an assignment for my CS class  
> requires me to prove that the obj is an instance of the singleton.  
> (And no, it's no trick question, the teacher has even lectured  
> about it and proposed a solution at the labs--- which btw I don't  
> buy).

Well, prove the teacher wrong showing that their definition of  
'instance of' is ambiguous.  You could take a test driven approach  
and write some tests that describe the expected behavior of a class  
and its instance.  Then try the tests against different types of  
objects:

   class/instance
   singleton-class/instance

I'll bet you find that there are some tests that work with class/ 
instance that won't work with singleton-class/instance but that the  
tests that the teacher suggested work for both cases.

> Pretending to be the devil's advocate, this could be explained away  
> (I *guess*) by claiming that the singleton class could have  
> provided a masking implementation of the class method.

I suppose but then you have to explain why the singleton class didn't  
provide a masking implementation of its own superclass method, which  
you don't want it to do since that would break
various other semantics in particular the behavior of singleton  
classes of classes and method lookup on class instances.

> I would say this much though: The singletons are fuzzy, (the slides  
> from David Black ignores and belittles the importance of the  
> implementation, and dare I say the principles behind them).

Well, there is an unresolved issue from Matz perspective.  The core  
idea is the notion of per-object methods.  That idea is currently  
implemented via the singleton class mechanism but, as we've  
discovered, somewhat awkwardly with respect to the normal inheritance  
hierarchy.  Within the language itself, there isn't even a 'name' for  
the construct since it is only accessible via an expression:

    (class <<x; self; end)

The most common terminology for that expression is 'singleton class'  
but some people like 'eigenclass' to distinguish the construct from a  
regular class that guarantees a single instance.
But in either case, you won't find 'singletonclass' or 'eigenclass'  
as a method name or keyword in the language or libraries.

Personally I'd really like to have a name instead of the expression  
since it seems everyone ends up defining their own name anyway via  
something like:

class Object
   def eclass
     (class <<self; self; end)
   end
end

But the particular name is different from one project to the next  
(eclass, metaclass, sclass, singleton_class, eigen_class, etc.)

I believe Matz said that he has finally decided that per-object  
methods are really and truly going to be officially standardized as  
instance methods of a 'per-object' class but he still hasn't  
committed to a standardized term for that 'per-object' class.  So for  
now it is still known officially as 'the class returned by the  
expression (class <<x; self; end)'.

Gary Wright