Twelve rules of Ruby
Panu Kinnari
something and in the progress become more knowledgeable about given
subject than most of the other people.
Original blogpost here: http://www.dilbert.com/blog/entry/rule_of_twelve
And followup with actual example:
http://www.dilbert.com/blog/entry/twelve_rules_of_energy_efficient_building/
Question I am proposing is found in subject line, what would be The
Twelve Rules for Ruby.
I am not that great programmer and one of the reasons for starting this
thread is to give some direction to my learning. And then to write more
code to actually learn.
I am not expecting for everyone to post 12 things, but maybe few that
they think should be included on this kind of list.
Thanks!
--
Posted via http://www.ruby-forum.com/.
Fabian Streitel
I'd say one of the main suspects here is closures:
returning from a block is different from returning from a lambda is
different from returning from a Proc, ...:
def f block
block.call
'f'
end
f(Proc.new { return 'Proc.new' }) #=> LocalJumpError
f(proc { return 'proc' }) #=> 'f' in 1.8, LocalJumpError in 1.9
f(lambda { return 'lambda' }) # => 'f'
def g
f(Proc.new { return 'Proc.new' })
'g'
end
g() #=> 'Proc.new'
etc. etc. See also this very nice summary here:
http://innig.net/software/ruby/closures-in-ruby.rb
If you know that, you should be able to impress a bunch of people *g*
Greetz!
David A. Black
Here's half a dozen. I would say that if everyone understood these
principles, and really stopped to think about them when puzzled by
something that Ruby was doing, or something that wasn't working in
their code, it would make a huge difference overall to people's
experiences learning and using Ruby:
1. Classes are objects.
2. Objects don't "have" methods; they have the intelligence to resolve
messages by looking for methods along their class/module lookup
path.
3. Every instance variable you ever see in any Ruby program belongs to
whatever object "self" is at that moment, without exception. (Which
is one reason that understanding how "self" gets assigned is
absolutely vital.)
4. A code block is a syntactic construct, not an object.
5. Class variables are not class variables, in the sense of belonging
to a particular class. They are class hierarchy variables.
6. Inheritance (A < B) is not the same as, and not related to, nesting
(A::B).
The first one on the list, alone, is worth the price of admission :-)
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)
David A. Black
a correctly-wrapped version, I hope.
1. Classes are objects.
2. Objects don't "have" methods; they have the intelligence to resolve
messages by looking for methods along their class/module lookup
path.
3. Every instance variable you ever see in any Ruby program belongs to
whatever object "self" is at that moment, without exception. (Which
is one reason that understanding how "self" gets assigned is
absolutely vital.)
4. A code block is a syntactic construct, not an object.
5. Class variables are not class variables, in the sense of belonging
to a particular class. They are class hierarchy variables.
6. Inheritance (A < B) is not the same as, and not related to, nesting
(A::B).
Tom Cloyd
t.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< t...@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Garry Freemyer
I would think that the twelve rules should be in the form of what things are, not what they are not.
It is also implied that the twelve rules would be something to learn early on .... so it's for those just starting to learn ruby.
The rules should then be reasonably clear.
To say that x is not a character does not tell me as much as telling me that x is an integer.
Saying that the identity of self may change and that its best to learn the rules of when it changes, does not tell me as much as finding away to tell me the rules.
David A. Black
On Tue, 14 Jul 2009, Garry Freemyer wrote:
> I would think that the twelve rules should be in the form of what
> things are, not what they are not.
>
> It is also implied that the twelve rules would be something to learn
> early on .... so it's for those just starting to learn ruby.
>
> The rules should then be reasonably clear.
>
> To say that x is not a character does not tell me as much as telling
> me that x is an integer.
>
> Saying that the identity of self may change and that its best to
> learn the rules of when it changes, does not tell me as much as
> finding away to tell me the rules.
http://www.manning.com/black2 :-)
I suppose I'm very teaching-oriented, in the sense that I'm mainly
interested in "rules" for understanding and using Ruby successfully. I
don't think there's that much point making a list of how self works[1]
in the absence of explaining why (at least in part) it's important to
understand it.
Of course, there are no twelve rules. Better is for everyone to
interpret the invitation how they see fit. We don't have to (and
won't, and can't) reach some kind of twelve-rule consensus. That's a
red herring.
David
[1] In a method definition, it's the object that received the message.
In a or module class definition body, outside of a method definition,
it's the class or module object. At the top level, it's a special
"backstop" object called "main". In an instance_eval or instance_exec
block, it's the receive of the instance_eval message. In a
class_/module_eval block, it's the class or module object. That's off
the top of my head (too lazy to look at the book sitting next to me
:-) but I think that's about it.
Marc Heiler
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 ... :>
Eleanor McHugh
> I would think that the twelve rules should be in the form of what
> things are, not what they are not.
>
> It is also implied that the twelve rules would be something to learn
> early on .... so it's for those just starting to learn ruby.
I think the point is that most people involved with Ruby - even those
with considerable experience - would be unlikely to consciously know
all twelve (or however many) of these rules. In that sense they're the
theoretical basis of expertise as opposed to competence.
Of course actual expertise cannot be distilled into an arbitrarily
small set of rules because it embodies much more than just theoretical
knowledge: you have to pay your dues if you want an instinctual and
wide-ranging grasp of any subject, mostly by making large numbers of
errors and then reflecting on their significance.
A couple of things I'd put on my personal list of Ruby rules:
1. Ruby is duck-typed. The type of an object is not the same as its
class and objects can (in a complex program at least some will) change
their identity at runtime. The only definitive type information
therefore comes from message passing.
2. Learn Ruby/DL or (j)ruby-ffi and leverage your platform for all
it's worth.
3. Metaprogramming is a right, not a privilege.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Garry Freemyer
________________________________
From: David A. Black <dbl...@rubypal.com>
To: ruby-talk ML <ruby...@ruby-lang.org>
Sent: Tuesday, July 14, 2009 7:43:56 AM
Subject: Re: Twelve rules of Ruby
Hi --
http://www.manning.com/black2 :-)
David
-- END of David's Reply.
Yep, I suspected myself that trying to state the rules might make a tome of a rule ... but those rules there are also worth the price of admission, Now i know what self is.
Just for curiosity I looked up the etiology of red herring and got this ... http://ask.yahoo.com/20010718.html
I looked at the book online with interest. One of the frustrations for me is that I have some older books on Ruby I bought a few years ago ... I got one that tells the student to try to implement something, and mentions that it is easy to do it wrong, but the author never explains what he thinks is the "Right" way of doing things. Now that I am laid off and urgently adding Ruby to my set of programmer skills, things in these books simply do not work any more and I am left to guess around trying to get things working.
Example: I am following an example from the book Ruby from novice to Professional .. and I am directed to use scaffolds to create my working project, but the procedure does not create a working program any more (The scaffold does NOT pick up the fields in the record, so trying to create a new record, just shows the header, the save button and the back button.
Neither me, nor my friend who has for years been making a living programming Rails and Ruby from his living room knows if this is a bug or an intentional change, or if there is some new syntax to make scaffold create a complete scaffold instead of a ladder with no rungs.
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
Eleanor McHugh
> 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).
David A. Black
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? :-)
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.
David
Rick DeNatale
> 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? :-)
>
> 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.
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.
--
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
James Britt
>> 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 ... :>
Related to this, objects do not have "attributes" or "properties"; they
have private instance variables that may be access by sending messages.
Typically those messages have the same name as the private instance
variable, but that's a convention, not a requirement.
Some Ruby literature encourages developers to think of objects in a more
Java-ish sense, as having public and private properties (i.e.
"attributes"), and the core idea of accessing private instance data via
message sending gets obscured. This makes later understanding of
metaprogramming harder than it need be.
--
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
James Britt
> 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.
Joel VanderWerf
> On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dbl...@rubypal.com> wrote:
>>>> Objects don't "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.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
David A. Black
On Wed, 15 Jul 2009, Joel VanderWerf wrote:
> Rick DeNatale wrote:
>> On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dbl...@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.
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.
Joel VanderWerf
> Hi --
>
> On Wed, 15 Jul 2009, Joel VanderWerf wrote:
>> 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.
Mike Stephens
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.
Ryan Davis
On Jul 14, 2009, at 06:16 , David A. Black wrote:
> Not sure why they wrapped weirdly (at least on my screen), but here's
> a correctly-wrapped version, I hope.
Rick did a very good job with some of the philosophical wanking but I
thought I'd expand a bit on David's list... I have to be a pedant now
and then :)
(please note, I'm still pre-caffeine... I'm sure I missed something in
the editing phase)
> 1. Classes are objects.
I prefer to tell my students: EVERYTHING is an object, even classes.
I think it conveys the ontology a bit better.
> 2. Objects don't "have" methods; they have the intelligence to resolve
> messages by looking for methods along their class/module lookup
> path.
See #1. Classes, modules, and their anonymous kin _have_ methods.
> 3. Every instance variable you ever see in any Ruby program belongs to
> whatever object "self" is at that moment, without exception. (Which
> is one reason that understanding how "self" gets assigned is
> absolutely vital.)
> 4. A code block is a syntactic construct, not an object.
See #1. EVERYTHING is an object, even blocks.
> 5. Class variables are not class variables, in the sense of belonging
> to a particular class. They are class hierarchy variables.
I know what you're getting at, but it might be worth having the
contrast of class instance variables in there so others understand too.
David A. Black
On Wed, 15 Jul 2009, Joel VanderWerf wrote:
> 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.
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 :-) 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 :-) 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 :-)
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 :-)
> 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 :-) 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 A. Black
On Wed, 15 Jul 2009, Ryan Davis wrote:
>
> On Jul 14, 2009, at 06:16 , David A. Black wrote:
>
>> Not sure why they wrapped weirdly (at least on my screen), but here's
>> a correctly-wrapped version, I hope.
>
> Rick did a very good job with some of the philosophical wanking but I thought
> I'd expand a bit on David's list... I have to be a pedant now and then :)
>
> (please note, I'm still pre-caffeine... I'm sure I missed something in the
> editing phase)
>
>> 1. Classes are objects.
>
> I prefer to tell my students: EVERYTHING is an object, even classes.
>
> I think it conveys the ontology a bit better.
Well -- either one is shorthand, in the sense that when actually
teaching the stuff, much more than one sentence is required :-)
>> 2. Objects don't "have" methods; they have the intelligence to resolve
>> messages by looking for methods along their class/module lookup
>> path.
>
> See #1. Classes, modules, and their anonymous kin _have_ methods.
Of course. Otherwise there wouldn't be much point looking for a method
along a lookup path of them :-) That's really the point of the "has"
thing: objects don't define or own the methods to which they have
access. At the very least, ownership is class-mediated, including as
between a class object and its own singleton class.
(I know the whole singleton class thing is an implementation decision,
but, at least for now, it's a decision, rather than an incidental
detail.)
>> 3. Every instance variable you ever see in any Ruby program belongs to
>> whatever object "self" is at that moment, without exception. (Which
>> is one reason that understanding how "self" gets assigned is
>> absolutely vital.)
>> 4. A code block is a syntactic construct, not an object.
>
> See #1. EVERYTHING is an object, even blocks.
I don't consider blocks or argument lists to be objects.
>> 5. Class variables are not class variables, in the sense of belonging
>> to a particular class. They are class hierarchy variables.
>
> I know what you're getting at, but it might be worth having the contrast of
> class instance variables in there so others understand too.
Do cut me some slack :-) I really wasn't trying to write a tutorial --
just a list of very succinct, suggestive, almost epigrammatic points.
David
Rick DeNatale
>
> On Jul 14, 2009, at 06:16 , David A. Black wrote:
>
>> Not sure why they wrapped weirdly (at least on my screen), but here's
>> a correctly-wrapped version, I hope.
>
>
> I prefer to tell my students: EVERYTHING is an object, even classes.
Well almost
> I think it conveys the ontology a bit better.
>
>> 4. A code block is a syntactic construct, not an object.
>
> See #1. EVERYTHING is an object, even blocks.
No, David makes a valid point. There is a difference in Ruby between
a block which is not an object, and a proc/lambda which is.
Also, variables are not objects either, they refer to objects, and
might be part of the state of an object (or on the invocation stack or
..) but they are not themselves objects. This is also true in
Smalltalk were we always used the same mantra of "everything is an
object." The mantra is not completely true in Smalltalk either.
This latter reminds me of the Daltonian model of atoms as indivisible
lumps, vs the current paradigm in Physics.
Ian Hobson
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
James Britt
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.
David A. Black
On Wed, 15 Jul 2009, Ian Hobson wrote:
> Joel VanderWerf wrote:
>> Rick DeNatale wrote:
>>> On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dbl...@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.
>>
>> 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.
lith
> messages by looking for methods along their class/module lookup
> path.
Since methods are bound to a certain evaluation context (ie the object
aka self), isn't that statement slightly simplicistic in that it
suggests a unidirectional relationship? The word "have" would IMHO
better reflect the reciprocal dependency. But English isn't my mother
tongue and maybe I got certain details wrong.
Panu Kinnari
grasp everything in it though :)
Eleanor McHugh
> On Tue, Jul 14, 2009 at 3:36 PM, Ryan Davis<ryand-
> ru...@zenspider.com> wrote:
>> See #1. EVERYTHING is an object, even blocks.
>
> No, David makes a valid point. There is a difference in Ruby between
> a block which is not an object, and a proc/lambda which is.
>
> Also, variables are not objects either, they refer to objects, and
> might be part of the state of an object (or on the invocation stack or
> Smalltalk were we always used the same mantra of "everything is an
> object." The mantra is not completely true in Smalltalk either.
>
> This latter reminds me of the Daltonian model of atoms as indivisible
> lumps, vs the current paradigm in Physics.
Much of this conversation (specifically regarding "has") reminds me of
the arguments over Bohm's Implicate Order.
As far as the physics of Ruby methods is concerned, they exist along a
search path and can only be said to belong to an object when that
search path is successfully queried in response to a message. How
that's modelled under the hood is irrelevant, and whether or not a
method is associated with an object when a message isn't being applied
is a philosophical question which cannot be answered with certainty.
Quantum mechanics 101 :)
Roger Pack
> 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
Robert Dober
> Rick DeNatale wrote:
>> On Tue, Jul 14, 2009 at 11:46 AM, David A. Black<dbl...@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.
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 ;).
--
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]