From: "David A. Black" Date: 2009-07-15T02:27:47+09:00 Subject: Re: Twelve rules of Ruby Hi -- On Wed, 15 Jul 2009, Joel VanderWerf wrote: > Rick DeNatale wrote: >> On Tue, Jul 14, 2009 at 11:46 AM, David A. Black wrote: >>>>> Objects don't "have" methods >> First of all, as you just stated, object DO in a sense have methods, >> in the same sense I have, say, an iPhone, because I know how to find >> it, usually. > > Yep. You said it better than I was about to (not just this line, but the > whole post). I was going to say "people don't 'have' bank accounts; they have > the intelligence to perform transactions by visiting a web site and entering > a password. I'm not sure what the point of these analogies is, I'm afraid. I don't think that the notion of "X has Y" is, or has to be, absolutely uniform across all usage and all values of X and Y. It's possible for humans to have bank accounts, and yet for the verb "to have" to be problematic in relation to Ruby objects and their methods. In fact, I believe that's how things stand. (It's also possible to get into the fine grain of what it means to "have" a bank account or a phone -- and I think in both cases it would transpire that "having" comes in many flavors [I can physically destroy a phone, even if you "have" it; you cannot produce a bank account on request and put it on the table, even though you "have" it; etc.] -- but that's not really that interesting, I think.) > As you 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. > 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".) Let me put the whole thing this way: encouraging people to let go, at least provisionally, of the notion that objects "have" methods and, instead, inquire into what goes on from the object's perspective in the process of resolving a message into a method, is very, very high on the list of things that I have seen, over the years, have an immediate, tremendous, permanent positive effect on people's understanding of Ruby and their ability to use Ruby productively. And it's absolutely upward compatible with being someone who is capable of taking on board (in due course) the fact that different interpreters work differently under the hood. There's no conflict there at all. David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Now available: The Well-Grounded Rubyist (http://manning.com/black2) Training! Intro to Ruby, with Black & Kastner, September 14-17 (More info: http://rubyurl.com/vmzN)