From: Joel VanderWerf <vjoel@...>
Date: 2009-07-15T03:29:12+09:00
Subject: Re: Twelve rules of Ruby

David A. Black wrote:
> Hi --
> 
> On Wed, 15 Jul 2009, Joel VanderWerf wrote:
>> As you [Rick] say, the location of such intelligence is a question that can
>> wait until someone starts poking around in the interpreter.
> 
> Yes and no. I'm all for poking into interpreters (if you don't believe
> me, see http://ruby-versions.net :-) but I absolutely don't believe
> that one has to hitch descriptions of Ruby's object model to
> descriptions of specific interpreters.

Exactly. There might be a compatible ruby interpreter in which each 
object really does "have", in every possible sense of the word, all of 
the methods that obj.send(:methods) lists. The difference between this 
and MRI with its own lookup algorithm is unlikely to matter to a 
beginner, as long as s/he has a consistent way of talking about the 
methods that an object responds to, and how they got that way.

>> For a beginner, it's more important to have a _model_ of how method 
>> lookup works (model in the sense of science, not rails). If the 
>> easiest way of stating this model is in terms of what methods an 
>> object has (and what class they were acquired from), so be it.
> 
> It's the easiest at the very beginning, but it quite quickly (say,
> early in the afternoon on the first day of training :-) becomes more
> of a hindrance than a help. Then, once someone understands what else
> is going on -- that is, once someone graduates to a more featureful
> model, one that encompasses more of Ruby's observable behavior --
> "has" reverts to being helpful, because it's the most sensible
> informal way of stating the relation between an object and a method.
> (Or "concise", if you don't like "informal".)

I'd explain these concepts in terms of the basic tools that I, even 
after years of rubying, still use to explore the capabilities of an object:

irb(main):001:0> s = "foo"
irb(main):003:0> s.methods.grep /slice/
irb(main):005:0> s.class.ancestors
irb(main):006:0> String.instance_methods(false)
irb(main):007:0> s.method :dup  # to find out where the method came from
=> #<Method: String(Kernel)#dup>

I still think of objects as having methods, because Object#methods tells 
me what methods an object has.

That's not incompatible with talking about how an object came to have 
those methods, and all the different ways that can happen.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407