From: Randy Kramer <rhkramer@...>
Date: 2008-09-20T09:40:24+09:00
Subject: Re: why one array continues to grow after repeated call

On Friday 19 September 2008 03:02 pm, Brian Candler wrote:
> However, you can't in Ruby. "x = y" cannot be made to mean anything 
> other than "evaluate the expression 'y', and store the resulting 
> reference in x" (*)
...
> In any case, it's nothing to do with the assignment operator. Note 
that:
> 
>   x = y         # *is not* a method call, and DOES NOT change ANY 
object 
> (*)
>   x[y] = z      # *is* a method call, and CAN change object(s)

Ok, I think this makes sense to me.  Trying to repeat for myself:

   * a method (is applied to and) can change an object

   * an assignment (evaluates an expression and) stores a reference (to 
that expression) in a variable

I'll try to let that sink in ;-)

> I don't think I can put it any clearer than that. These really are 
> completely different. Also, since "x = y" involves no method call, 
it's 
> not possible to overload it or change its meaning in any way.

OK.
 
> Aside: the [] operator may *look* like looking up an element in an 
> array, but it is very common for it to be used as something else.
> 
>   m = lambda { |x,y| x+y }
>   puts m[3,4]   # prints 7
> 
> HTH,

Brian,

Yup, thanks, I think I'm getting there--I appreciate your patience.  
I'll reread all your emails a few times over the next little while.

> (*) Note that 'y' could be a local variable, but it could be a method 
> call.
> 
>   def y
>     "hello"
>   end
>   x = y
>   puts x
>   y = 123
>   x = y
>   puts x
> 
> And therefore if it's a method call, invoking that method *could* 
modify 
> objects as a side-effect.
> 
> Whether a bare "y" is a method call or a local variable depends on a 
> static, parse-time decision. If an *assignment* to a local variable y 
> was parsed earlier in this scope, then it's a local variable. Note: 
> "parsed" - not executed. So:
> 
>   def foo
>     "hello"
>   end
> 
>   if false
>     foo = "goodbye"
>   end
>   puts foo     # prints nil
> 
>   # But you can force the method call interpretation:
>   puts self.foo
>   puts foo()
> 
> I mention this now because it hopefully it reinforces the need to 
> recognise a true assignment, versus something which is actually a 
method 
> call.

Interesting!

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