From: J2M <james2mccarthy@...>
Date: 2006-12-13T21:10:07+09:00
Subject: Re: How do I catch a missing method on a passed block?


dblack@wobblini.net wrote:

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

This is a useful summary of the key concepts that moved me forward. I
have a long way to go, but it clearly encapsulates the crossing of a
rubicon (sic).

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

Absolutely, the questions I raised on this thread were founded in a
need to know how to apply these concepts, which is why everybody's
feedback has been incredibly valuable. I may have grasped the concepts
but the application takes a little longer.

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

Erik's code offered a clean way of extracting some of the aspects that
can be re-used, whether I call the remaining code business logic or not
in this example is irrelevant, but it does present a neat way of
structuring things but being reminded that I have a lot to learn
doesn't always feel great!

The big lesson I got from Erik was in reflecting on both your comments
and Erik's example code is the clarity of understanding comes from the
ability to grasp and reflect on a number of principles concurrently.
That can be a very hard thing to do - keeping all those principles in
mind at the same time. Breaking the code into those 3 methods helped
encapsulate those concepts in a way that was less effort to think
about. To me it wasn't about inspiring awe but rather removing the
complexity.

James