Randy Kramer
9/18/2008 9:02:00 PM
[Note: parts of this message were removed to make it a legal post.]
On Thursday 18 September 2008 02:52 pm, Brian Candler wrote:
> 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
My comment on assignment was sort of a digression (not my main point), but, nevertheless, I can do the following while using object_id (as suggested in your followup) to confirm that I'm still dealing with the same object. (a was leftover from some previous "exercise"):
irb(main):098:0> a
=> [nil, nil, 5, nil, nil, nil, nil, nil, nil, "testy", "foo"]
irb(main):099:0> a.object_id
=> -605519610
irb(main):100:0> a[2] = 3
=> 3
irb(main):101:0> a
=> [nil, nil, 3, nil, nil, nil, nil, nil, nil, "testy", "foo"]
irb(main):102:0> a.object_id
=> -605519610
irb(main):103:0> a.[]=(2,4)
=> 4
irb(main):104:0> a
=> [nil, nil, 4, nil, nil, nil, nil, nil, nil, "testy", "foo"]
irb(main):105:0> a.object_id
=> -605519610
irb(main):106:0> a.send(:[]=, 2, 5)
=> 5
irb(main):107:0> a
=> [nil, nil, 5, nil, nil, nil, nil, nil, nil, "testy", "foo"]
irb(main):108:0> a.object_id
=> -605519610
So, what is the net effect? With any of the three syntaxes (a[2] = 3, a.[]=(2,4), a.send(:[]=, 2, 5)), I change (assign a new value to) the 3rd element of the array a.
What is the practical point of saying it is not an assignment? Yes, I know that the underlying thing is a method, and somehow a[2] = 3 is syntactic sugar (I guess), for a.[]=(2,3), but in the end, it accomplishes an assignment.
I'm not intentionally trying to be obstinate, it just seems there is no practical impact to what happens, or to my thinking process as a programmer, to not consider a[2] = 3 an assignment.
> 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.
I'm assuming the same is true for any variable in Ruby, not just local variables?
> > 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 */
Ok, is there still some magic here?. Compare (thinking in C):
Given:
char *a;
char *c;
Would both of these assignments (in C) work as they would in Ruby:
a = [1, 2, 3]
c = a
... or would the first one have to be something like:
a = &([1, 2, 3])
> 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).
Ahh, that's helpful, I've often wondered what made a pointer a reference instead.
> 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.
Ok. And it's the same in C for pointers, iiuc.
> HTH,
Yes, thanks!
Randy Kramer
--
I didn't have time to write a short letter, so I created a video instead.--with apologies to Cicero, et.al.