From: Eero Saynatkari <ruby-ml@...>
Date: 2005-11-07T11:45:45+09:00
Subject: Re: Access control and class methods

gwtmp01@mac.com wrote:
> 
> On Nov 6, 2005, at 9:47 AM, Mads Kristensen wrote:
> 
>> And BTW: what does class<<self actually mean? One < would be  
>> inheritance but what does it mean when there are two?
> 
> 
> One of the early hurdles I had with Ruby was trying to map
> the "class <<object" syntax into a useful mental model.  I'm
> not sure why "<<" was selected.  The semantics and syntax
> don't seem to be related to those of the "<<" operator and
> so you really need to form two separate mental models and just
> know which one applies.

Well, it does bear some relation to inheritance which is why,
I would assume, the syntax was chosen. This...

   class << foobar
     # ...
   end

...to me reads something like 'create an unnamed class which
inherits from foobar' and while not entirely accurate, illustrates
the basic idea of creating a special class/object based on some
existing object (foobar above) and defining behaviours on it.

In actuality, of course, the relationship is inverted as we are
not inheriting foobar but indeed making foobar inherit from a
new class but the end result behaves more or less the same.

> Why not something like:
> 
> class obj.eclass
>   #
> end
> 
> Where Object#eclass is defined to return the eigenclass of
> the receiver?  Even a different keyword would be clearer:
> 
> eclass obj
>   #
> end

There was some debate about what the class should be called
(I still think #pouch). Also, the irreplaceable _why took it
upon himself to write a good description of Ruby's metaclasses.

   http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html

There is also a small set of methods towards the bottom to help
dealing with metaclasses. Wrap it up in a file, put a notice
thanking _why for his contribution and use it with your code.

> It isn't a big deal but it does confuse newbies.
> 
> 
> Gary Wright

E