From: Kedar Mhaswade <lists@...>
Date: 2013-03-14T21:57:35+09:00
Subject: Re: Understanding Ruby Classes, Objects and Methods.

Thanks, Robert!

> abc is an instance of String
> This is not true. Said expression is a constructor of a String which
> will return a different String instance on every evaluation.

I don't find that statement in the doc. I only have:

2. "abc" is an instance of String.

and I believe that is correct because String is the class of all strings 
in Ruby.

>
> "Depending upon the data type of the object, a variable is a name for
> the object itself or a reference to it."
> In an introductory text I would not _start_ with this statement.
> Better: "A variable is a place that stores a reference to an object."
> Same for your treatment of "immediate values". This is really an
> implementation detail which should be taught much later.  I think it
> helps understanding if one does _not_ bring this up that early.
> Actually, from a point of view of the user of the language it does not
> matter _at all_ (only for performance, but not functionality wise).

I agree. But integers is what many of us start with playing in irb. So, 
I thought it was appropriate to recognize the difference between 
instances of String (e.g. "abc") and those of an Integer (e.g. 1).

>
> "If the method were not found in String, Ruby would have followed the
> superclass (sc, green arrow) links in search for the method
> definition." and "It creates a new anonymous class object and inserts
> it into Foos superclass chain!"
> This is not true.  The chain of classes and modules found via
> Module#ancestors is traversed instead.  There is no need for a new
> anonymous class.  The only place where new classes are automatically
> allocated is the singleton class of an instance.
>

I see. But I thought Dave Thomas also says something similar (in his 
book) to what I wrote. The topic is about including Modules in Classes. 
Even if you say that the chain returned by ancestors is traversed, where 
is the reference for code for something like Mod#m? Since the same 
module Mod can be included in several classes, an instance of anonymous 
class for each including class seems right. But I agree, I don't yet 
know how this happens internally in the interpreter.

Also, I tried to logically explain why included module's methods _have 
to_ get preference over those inherited from superclasses.

> I stopped reading there as I found your diagram about singleton quite
> complicated and unclear.
>

Not a problem. I will try to clarify the diagrams. Alas, they are not 
doing their job :-(. But I believe they are correct (and this stuff is 
complex).

> Cheers
>
> robert

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