Joel VanderWerf wrote:
> Wilson Bilkovich wrote:
> ...
> 
>>What are some key points I should make sure to cover for procedural programmers?
>>Things on my list so far:
>>1. Variables don't hold values, they are just labels.
> 
> 
> We hear that a lot, but, somehow, it never sounds right. If variables
> are labels, why don't they follow the object around, and become
> accessible to other users of the object? How do I calculate how many
> labels an object has? Is a label an object? Can you change the text of
> the label? Do they ever fall off when the glue dries out?

I'd say that they're not "labels" in that sense, but in the sense of
names -- as "Joel" is a label for you, but no medical exam will ever
reveal your name.

Or (dumb analogy of the day) a variable is a pair of binoculars trained
on an object. No way of telling how many others may be watching. And no
way an object knows who is out there pointing to him.

> Anyway, variables *do* hold some kinds of values, like numbers,
> booleans, and symbols, in almost exactly the way that C variables "hold"
> values. Ironically, the only thing that ruby variables hold *is* VALUE,
> as it is called in the source.

True from an implementation perspective. But in practice, we don't really
need to know that. It's more important IMO to distinguish between
mutable and immutable than between immediate and non-immediate.


> This may seem extreme, to look at the implementation on the first day.
> But it is very concrete, enough to inoculate against the usual
> confusions: Is ruby pass-by-reference or pass-by-value? Why are there
> are no destructive methods on Fixnum or Symbol?

Again I'd say: Pass by value, where every value is a reference.

> In general, I don't think it can hurt to be concrete, or to at least
> give a concrete view of things as an alternative. For example, message
> evaluation happens by looking up a symbol in the receiver's table, and,
> if no entry is found, iterating up the superclass tables. For some
> people (esp. those with a procedural background), that means a lot more
> than "this object over here sends a message to that object over there,
> which can either respond to it or let its superclass handle it".

It doesn't hurt to know a little about internals. But a language should
be taught from the outside in, not inside out IMO.


Hal