On Thu, Mar 14, 2013 at 1:57 PM, Kedar Mhaswade <[email protected]> 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/
--
[email protected] |
https://groups.google.com/d/forum/ruby-talk-google?hl=en
---
You received this message because you are subscribed to the Google Groups
"ruby-talk-google" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
