Twelve rules of Ruby

ruby-talk
21

I know what you are driving at, but there are some things about your
statement of that rule which bother me.

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.

And the idea that "they have the intelligence to resolve messages by
looking for methods along their class/module lookup path" is a bit of
a pedagogical lie. If an object has any intelligence that
intelligence is held in its methods, and state. Objects don't really
know how to find their methods, it's the implementation of the
language whether you call that an interpreter, or a virtual machine,
which knows how to do that.

How best to think about such things depends on where you are on the
journey of learning. A certain perspective can get a learner over a
hump, even it it's not exactly correct. But it can also lead to the
stuff you and I were tweeting about a few days ago, when I discovered
that there are adults in this world who firmly believe that Two
Thousand and One, means 2000.1 because their fourth or fifth grade
minds were taught that "and means decimal point," and never realized
that this was a shortcut way of telling them that when they see a . in
a digit string, it means decimal point and they should say "and" and
then the following decimal fraction.

At one level, the important thing is to be able to reason about how
methods are found based on the reference implementation of chained
classes and model proxies in MRI. On the other hand, this approach is
actually talking about a shadow of the implementation displayed on the
walls of Plato's cave. There are certainly conceivable Ruby
implementations which used a more Self, or JavaScript like object
model, in which methods were more closely associated with instances,
but still acted AS IF they had the MRI implementation for all outside
observers.

In my years dealing with language standards, I've learned the power of
that explicit 'AS IF' to separate intent from implementation.

···

On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dblack@rubypal.com> wrote:

Hi --

On Wed, 15 Jul 2009, Marc Heiler wrote:

Objects don't "have" methods

Hey David, you gotta tell this Dave Thomas so that he can talk about
this in new pickaxes too. I sort of stopped learning after reading
pickaxe, because this concept still surprises me ... :>

That's what keeps it interesting, isn't it? :slight_smile:

I certainly use the "have" terminology informally. But it's important
to understand that "obj has a 'talk' method" is really shorthand for:
"obj can successfully resolve the message 'talk' because there is a
'talk' method definition in one of the classes or modules in its
method lookup path." The wordier version will enable you, for example,
to understand super, inheritance, include, extend, the difference
between undef_method and remove_method, and various other things...
whereas "has", while a handy shorthand, doesn't pan out as a real
description of the object model.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

22

Eleanor McHugh wrote:

···

On 14 Jul 2009, at 16:24, Garry Freemyer wrote:

The reason I bring this frustration out, is I am interested in finding a book that doesn't leave me in the lurch of having to make guesses with no guidance, and where the examples work with the current version of ruby in wide use today. Surprises are like being in a dark cave and having your flashlight go out without warning.

My rails is 2.3.2 and Ruby version 1.8.6

I can't comment on the Rails side of things as that's not my primary interest, but for Ruby 1.8.6 the second edition of the PickAxe and David's excellent Ruby for Rails should get you up to speed on the language. I also recommend the second edition of The Ruby Way by Hal Fulton which is full of interesting snippets (and there's also The Rails Way of which I've heard good reports).

Grab Greg Brown's Ruby Best Practices, too.

--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development

23

Rick DeNatale 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.

As you say, the location of such intelligence is a question that can wait until someone starts poking around in the interpreter.

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.

···

On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dblack@rubypal.com> wrote:

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

24

Hi --

Rick DeNatale 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 :slight_smile: 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 :slight_smile: 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

···

On Wed, 15 Jul 2009, Joel VanderWerf wrote:

On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dblack@rubypal.com> wrote:

--
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\)

25

Joel VanderWerf wrote:

Rick DeNatale 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.

As you say, the location of such intelligence is a question that can wait until someone starts poking around in the interpreter.

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.

Hi Joel,

I agree that a beginner needs a model. It is (IMHO) more important that the model helps him achieve his goals, than is accurate to the Nth degree. A rule of thumb - it must not miss-lead.

The art of learning is to update your models as you need them updating, so you are neither miss-led by their shortcomings or tricked into error. I see the ability to help with this, as a key skill for anyone who professes to teach or educate.

Knowing when to discard a model, and how to persuade someone to do it, are really interesting (and I think important) questions.

Regards

Ian

···

On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dblack@rubypal.com> >> wrote:

26

Probably. I feel that David is right, well I know he is, on technical
grounds. However I also feel that Rick and Joël are right. I have made
up a model in my mind that reads as follows:

Objects have methods, but if you run into any troubles just remind
that all those methods are stored in objects that happen to be modules
and none in the object itself.
Singleton methods are therefore stored in a singleton class which is
not shared with any other object.

Works for me ;).

···

On 7/14/09, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

Rick DeNatale wrote:

On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dblack@rubypal.com> >> 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.

As you say, the location of such intelligence is a question that can
wait until someone starts poking around in the interpreter.

--
Toutes les grandes personnes ont d’abord été des enfants, mais peu
d’entre elles s’en souviennent.

All adults have been children first, but not many remember.

[Antoine de Saint-Exupéry]

27

David A. Black wrote:

Hi --

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 :slight_smile: 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 :slight_smile: 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.

···

On Wed, 15 Jul 2009, Joel VanderWerf wrote:

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

28

Hi --

Joel VanderWerf wrote:

Rick DeNatale 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.

As you say, the location of such intelligence is a question that can wait until someone starts poking around in the interpreter.

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.

Hi Joel,

I agree that a beginner needs a model. It is (IMHO) more important that the model helps him achieve his goals, than is accurate to the Nth degree. A rule of thumb - it must not miss-lead.

A lot of what's involved in teaching, too, is deciding what *not* to
say. I think that for many people, when they first try teaching,
there's almost a feeling of guilt if something occurs to them, in the
course of explaining something, that's sort of relevant but really
tangential and they don't say it. But of course if you do say
everything, the student can't tell that some of it is -- so to speak
-- in parentheses. There's an art to cutting yourself off and keeping
to the main path (knowing, of course, that other things can be
revisited later).

The art of learning is to update your models as you need them updating, so you are neither miss-led by their shortcomings or tricked into error. I see the ability to help with this, as a key skill for anyone who professes to teach or educate.

Definitely. It's not the whole story, but it can be important. Another
interesting point is that sometimes your models have models. For
example, we're really talking about two things in this thread: the
Ruby object model, and ways of framing and explaining that model so
that people can understand and assimilate it. It's interesting to
think about how those things interact and combine.

David

···

On Wed, 15 Jul 2009, Ian Hobson wrote:

On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dblack@rubypal.com> >>> wrote:

--
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\)

29

The original example was about how to approach keeping your house cool,
not a manual on the innards of air conditioning. It said, for example,
don't bother about the walls because the roof is more important.

On that basis my first rule would be:

1) Don't worry about any Ruby feature that you don't need to use. It's
very, very powerful but unless you need to write something like Rails or
you are an astrophysics PhD, then ignore all the fancy stuff.

···

--
Posted via http://www.ruby-forum.com/.

30

Hi --

David A. Black wrote:

Hi --

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 :slight_smile: 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.

The things I'm talking about are not MRI quirks, though; they're ways
of modeling why things happen the way they do in (what I still insist
on thinking of as :slight_smile: Ruby itself. I definitely do not believe it's a
good idea to embargo all observations about the Ruby object model,
beyond "objects have methods", on the grounds that they're just
artifacts of MRI.

super is a good example. A lot of people who've used Ruby for a while
have a general -- or, I should say, specific -- idea that super calls
"the same method, in the superclass".

Consider this code:

   module M
     def talk; puts "In M"; end
   end

   class A
     include M
     def talk; puts "In A"; super; end
   end

   a = A.new
   a.talk # => In M\nIn A

Two observations. First, any interpreter that did not produce the
above results -- and for which an account involving method lookup
along a class/module path therefore did not make sense -- I would not
describe as a Ruby interpreter. Obviously, if Matz removes classes
from Ruby (or whatever), things will change. But as of today, and the
foreseeable future, Ruby produces that result.

Second, I see no reason to tie my hands, in trying to account for the
behavior of super (and a whole bunch of other things), by ruling out
of court an account of the method lookup heuristics of the Ruby object
trying to resolve a message. I don't mind if it's slightly
anthropomorphic, or if parts of it are optimized away by such-and-such
an interpreter. The high-percentage thing, at least for someone
learning Ruby, is to gain the ability both to understand as much code
as possible and to bring as many productive techniques as possible to
bear on writing code.

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 :slight_smile: 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>

Yes, that would be chapter 15 :slight_smile:

The thing is, I'm a great non-believer in the "winner take all",
zero-sum approach to these things. Prompting people to rethink the
notion of an object "having" methods, so that they start to see the
message-resolution heuristics more clearly, in no way entails *not*
using the techniques you've listed here for explanatory purposes. I
don't feel I have to choose.

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

(Or which ones it will be able to find on its lookup path :slight_smile:

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

Right -- thus one circles back to it. Believe me, I'm not the "has"
police :slight_smile: I say "has an x method" all over the place. I just find
that teaching people that there's more going on -- and, specifically,
positioning that "more" as residing under the hood of the "has" -- is
very productive.

David

···

On Wed, 15 Jul 2009, Joel VanderWerf wrote:

On Wed, 15 Jul 2009, Joel VanderWerf wrote:

--
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\)

31

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 just learned something--I didn't know you can infer a methods owner
even in 1.8. Nice.

=r

···

--
Posted via http://www.ruby-forum.com/\.

32

Mike Stephens wrote:

The original example was about how to approach keeping your house cool, not a manual on the innards of air conditioning. It said, for example, don't bother about the walls because the roof is more important.

On that basis my first rule would be:

1) Don't worry about any Ruby feature that you don't need to use. It's very, very powerful but unless you need to write something like Rails or you are an astrophysics PhD, then ignore all the fancy stuff.

It's the Blub thing.

What's "fancy" depends on one's exposure. You often can't know you need something unless you've already spent some time understanding it.

People who come to Ruby from, say, VB, will likely find the notion of list mapping or injection pretty alien. And they may never see where they need to use it, because they've never had to deal with code that included those concepts.

To become proficient at a language you need to force yourself out of your comfort zone and get acquainted with different ways of solving problems.

···

--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development