On Thursday 18 September 2008 09:01 am, Rick DeNatale wrote:
> Perhaps this two year old article in my blog might give some insight
>http://talklikeaduck.denhaven2.com/articles/2006/09/13/on-variables-values-and-objects

I'm not the OP but I took a quick glance at the article.  Sometime when 
I have more time to study it, it may help me a lot, but I had some 
trouble with it, and comments about it.  I would have left them on that 
page but it appears comments are disabled.

The area where I had my first problem was around here:

<quote>
Mutability, and Aliasing

Here's one of those stumbling blocks for those who expect variables in a 
uniformly object-oriented language to work like they do in a language 
like C or Fortran: 

 1: a = [1, 2, 3]
 2: b = [1, 2, 3]
 3: c = a

 4: a[1] = 0

 5: p a #=> [1, 0, 3]
 6: p b #=> [1, 2, 3]
 7: p c #=> [1, 0, 3]

...

Line 4 might look like an assignment to the variable a, but it's really 
a method call to the array which a happens to be referencing at the 
time. And that method (called []=) changes, or mutates that array. That 
change will be visible through the variables a, c and any others that 
reference that particular array. Multiple references to the same object 
are called aliases to that object. They might be named variables, or 
referenced which are inside another object:
</quote>

The statement "Line 4 might look like an assignment to the variable a, 
but it's really a method call to the array which a happens to be 
referencing at the time." is almost like a red herring for me--it's 
really not (imho) the thing that is important at that moment in your 
example.

The really important thing is the previous statement, and how it works 
(and asignment in general, whether you call it a method or whatever):
 
3: c = a

To me, the thing that is interesting (and finally sinking in) is how 
assignments work.  (I'm not sure whether I've read this before 
somewhere or not.)

What I think will help me is recognizing (I think this is true) that 
assignments work in different ways, as follows:

If you assign an object to a variable (like a = [1, 2, 3]), the 
assignment works as expected (or at least as most of us expect, I 
think ;-)  

(I know that's not completely true at the level of Ruby internals--a 
isn't the memory containing the array [1, 2, 3] but instead in some (as 
you say on the page) pedagological (sp?) sense, points to the memory 
area containing the array [1, 2, 3].)

In contrast, when you (attempt to) assign a variable to a variable, Ruby 
does something that is a little surprising (at least to me, and perhaps 
to others coming from, for example C).  Instead of assigning a (the 2nd 
variable) to c (the 1st variable), Ruby seaches out the object to which 
the variable "points" (the object which the variable references--the 
array [1, 2, 3]), and assigns that object to c.

I'm not a C programmer (have tried to learn at times), but it is almost 
like the Ruby assignment a = c is handled more like (hmm, I'm trying to 
think of the right C syntax, would it be):

c = *a  (or would that be c = &a--darn)

(So, at first glance, c is automatically something like a pointer.  I 
guess in Ruby terms, that's what is called an alias.)

Furthermore, I suspect that you can't just do anything you want (like 
you might in C) with that new pointer to a--what do I mean?  Well, c 
doesn't have any notion of a anymore--c is a pointer (reference) to 
what a contained, but it is "direct", it doesn't go through a in any 
sense after the assignment.  (What could I do with it in c--can't think 
of anything atm.)

Ok, I guess that's why it's called an alias--it's another name for that 
object.

Anyway, I think this will help me, unless it collides with reality at 
some point.

Am I totally off base?

Randy Kramer
-- 
I didn't have time to write a short letter, so I created a video 
instead.--with apologies to Cicero, et.al.