From: dblack@...
Date: 2006-12-13T10:48:08+09:00
Subject: Re: How do I catch a missing method on a passed block?

Hi --

On Wed, 13 Dec 2006, Erik Veenstra wrote:

> I've some comments, on almost all code in this thread. Feel
> free to ignore me...
>
> All code is "polluted" with meta-code stuff and "class <<
> object" stuff and "instance_eval" stuff and "class_eval" stuff
> and other stuff. That doesn't feel good. Well, you need this
> code to do the trick, but...

I guess "polluted" is relative.  I admit I've never understood the
fuss that people make over these things, one way or the other -- that
is, I neither see them as a badge of some kind of wizardry, nor think
that they are to be shunned or stigmatized.  They're just ways to live
productively in the Ruby landscape, where there are objects and
objects have singleton classes and there's a 'self' and so on.  I
guess class << obj requires more ramping up than x = 1, but on the
whole I think Ruby is much flatter than it's often given credit for.

Most of what people need to grasp and embrace, in order to understand
and use the vast bulk of these techniques, and others, is:

   * classes are objects
   * each object (or almost each object) has both a "birth class" and a
     singleton class
   * objects don't have methods; they look for them along a
     class/module search path, with well-defined rules of order and
     inclusion
   * there's one and only one 'self' at every point in the program
   * instance variables belong to 'self', always
   * class variables are completely unrelated to instance variables,
     in spite of the use of @ in one and @@ in the other
   * the def and class keywords start new local scopes
   * the class keyword can take either a constant (for a named class)
     or a "<< object" expression (for a singleton class)

I'm not saying that's the whole language, of course; but probably
about 90% of the problems I've seen people have with Ruby over the
years -- with the language generally, with understanding code they
see, and with solving specific problems in their own code -- come from
not understanding one or more of these points.  Class variables are
perhaps the worst offenders: they cause no end of confusion.  The role
of 'self', particularly as it governs ownership of instance variables,
is also a bit of a hurdle -- but not insurmountable.

I'm all for organizing code nicely, and grouping together things that
belong together, as you suggest.  But what's been concerning me
recently is that it feels like people are being encouraged to feel
awestruck and out of their depth when they see "class << object".
Yes, it looks different from "class C" but I just don't think it's
*that* big a deal.  The underlying principles are relatively few; the
language is expressive; and it all works together rather nicely.


David

-- 
Q. What's a good holiday present for the serious Rails developer?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    aka The Ruby book for Rails developers!
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)