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

It's crucial.  x[y] = z "looks" very much like some sort of an 
assignment. BUT IT ISN'T AT ALL.

It is exactly the same as:  x.[]=(y,z)

or:

x.send(:[]=, y, z)

(you get into smiley programming if you do that :-) It's a method call 
to object x; the method has the ungainly name "[]="; and the arguments 
are y,z

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

Yes, that's very important too. You are assigning to a local variable, 
which is just a slot on the stack. A local variable is in fact one of 
the few things which is *not* an object in Ruby. It *holds* a reference 
to an object, but is not an object itself.

> 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 a quite accurate sense, 'a' is a pointer to the memory 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.

No. It simply copies a to c. a contains a pointer to the array, and so 
now c also contains a pointer to the same array. It's really that 
simple.

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

No, it's "c = a" in C as well.

  char *a;
  char *c;

  a = malloc(123);  /* a points to some memory */
  c = a;            /* c points to the same memory */

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

They're called "references", to distinguish them from pointers because 
you can't actually use them as pointers (e.g. you can't "increment" the 
pointer to point to the next area of memory, as you can in C).

Aliases are just multiple references/pointers to the same thing. But an 
object has no idea how many of these may or may not exist.

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

You can do exactly the same with a and c. They are exactly equal in 
contents and power.

  a.first
  c.first

both invoke the method "first" on the same object.

HTH,

Brian.
-- 
Posted via http://www.ruby-forum.com/.