On Fri, Nov 12, 2010 at 7:04 PM, Robert Dober <robert.dober / gmail.com> wrote:

> Completely!

Aaahhh, perfect :).

> I agree that we have pass by value. My question is, why do you dislike
> this representation for it
>
> def meth a
> ...
>
> meth(b)
>
> a ---+
>    |
>    +------> An Object
>    |
> b---+
>
> I thought it was making things quite clear
> Maybe one should add that after
>
> b = 42
>
> the picture changes.

Because I think the object at the end of the arrow may be misleading
for explaining call semantics.

Problem is those arrows do not mean storage, in my view we really have
two types of arrows. First arrow is

    the variable a _stores_ the reference 2158949300

That's what matters for call semantics, what does the variable hold.
It does not matter whether that integer is a pointer, and if it is a
pointer what does it point to.

A second arrow of a different type points to an object from the pointer box

    2158949300 _refers to_ "say, some string"

That information is helpful and gives the whole picture about how
method invocation relates to objects, but it is in my view beyond call
semantics.

In that sense the diagrams of my post are not clear enough for
depicting what the post wants to explain, I think I'll revise it to
include the reference/pointer boxes.

-- fxn

PS: I have to say that those arrows and boxes match the observed
behavior and MRI implementation, but the spec as far as I can tell
does not imply them with 100% confidence in my opinion.

I do believe that's what the spec *wants* to specify, but the word
"reference" is not used, and the verb "copy" does not appear either.
My interpretation is that the first is there via the verb "refers",
and the fact that variables are not objects. And that in method
invocation "copy" is obviated because we are dealing with pointers and
the mere described assignment is enough. I've written to Matz about
this.