From: Robert Klemme Date: 2013-03-14T22:28:07+09:00 Subject: Re: Understanding Ruby Classes, Objects and Methods. On Thu, Mar 14, 2013 at 1:57 PM, Kedar Mhaswade wrote: > Thanks, Robert! You're welcome! >> 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. Yes, that's it. > and I believe that is correct because String is the class of all strings > in Ruby. irb(main):001:0> 5.times { s = "abc"; p s.object_id } -1073589128 -1073589178 -1073589208 -1073589228 -1073589268 => 5 >> "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). The fact that Fixnums are immediate values is _completely_ irrelevant for how they are used. >> "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. I don't have the book handy. Maybe you can quote the relevant text. > 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. So you say you do not know how it works but claim there is an anonymous class - solely because it "seems right"? Why does it "seem right"? I had though you wanted to convey facts. > Also, I tried to logically explain why included module's methods _have > to_ get preference over those inherited from superclasses. You do not need anonymous classes for that. >> 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). I didn't say "all". Just the singleton class diagram put me off. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/