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:
- “abc” is an instance of String.
and I believe that is correct because String is the class of all strings
“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 T. 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