Drowning in a teacup?

[Steven D'Aprano]

On Sun, 3 Apr 2016 05:54 am, Random832 wrote:

> On Sat, Apr 2, 2016, at 15:28, Ned Batchelder wrote:
>> On Friday, April 1, 2016 at 4:27:30 PM UTC-4, Fillmore wrote:
>> > notorious pass by reference vs pass by value biting me in the backside
>> > here. Proceeding in order.
>> 
>> As others have pointed out, this is false dichotomy.  There are other
>> possibilities than pass by reference and pass by value.  Python (and
>> many other languages) use something called pass by object or pass by
>> sharing.
> 
> I think that this arises from a confusion as to what a "value" is in
> "pass by value".

I don't understand what you mean by this. Are you defending the idea that
Python is pass-by-value, or saying that Fillmore is confused by what
pass-by-value means, or something else? What precisely are you trying to
say here?



> The point of it being pass by value is that there is no statement you
> can execute in the function that has the effect of an assignment of the
> expression that was passed in from the caller. 

No, that alone is insufficient. There are other calling conventions that
have the same effect. Pass-by-value also requires that the value being
passed is copied.

Unfortunately we've been plagued by a bunch of comp sci graduates who suffer
from the "little bit of learning" problem. Having learned that there are
only two calling conventions, pass by value and pass by reference, and
correctly recognising that their language of choice is not pass by
reference, they then jump through some remarkable intellectual contortions
to prove that it is therefore pass by value.

To do this, they normally redefine "value" to mean something other than what
everyone else thinks of as the value being passed to a function.

The Java community is especially prone to this:

http://javadude.com/articles/passbyvalue.htm

Note the author's definition of pass-by-value:

[quote]
Pass-by-value

The actual parameter (or argument expression) is fully evaluated and the
resulting value is copied into a location being used to hold the formal
parameter's value during method/function execution.
[end quote]


That the value is *copied* is fundamental to pass by value semantics.

The author, Scott Stanchfield, then claims that Java is pass by value. 

(Note: for this entire discussion, I'm referring to boxed values, or
objects, not primitives. There's no dispute that Java is pass by value for
primitives.)

But to make this work, he has to use a bit of slight of hand: what gets
copied in Java function calls is not the value of the argument, but some
abstract reference to that value. There's this invisible abstract reference
is the value of the variable.

He doesn't come right out and say this, but if you read his description of
what Java does, it should be obvious that he thinks of Java variables as
being bound to abstract pointers or references rather than being bound to
objects themselves. Consequently, if you bind a value to a variable name:

String str = "Hello";

then to Stanchfield, the value of the string variable str is presumably
not "Hello", but some unknown and unknowable abstract reference like
0x832fe50.

This is the only way to make sense of his argument. Objects are not copied
when you pass them to a function in Java, but the invisible reference to
the object may be. Fredrik Lundh (the Effbot) quite rightly holds this view
in scorn:


[quote]
I guess you can, in theory, value an artificial number assigned
to an object as much as the object itself.

    "Joe, I think our son might be lost in the woods"
    "Don't worry, I have his social security number"
[end quote]

http://effbot.org/zone/call-by-object.htm


Stanchfield's view of invisible references to objects being passed by value
is, I have no doubt, right from the perspective of the Java implementation.
Some would argue that he is "technically correct". But he is answering the
wrong question. Calling Java (or Python) "pass by value" gives us no
insight into how the language works. It is reductionism gone mad.

Nobody, except maybe compiler designers, cares how the Java virtual machine
implements argument passing. What Java developers care about is the
behaviour of the Java language. Java's so-called "pass by value (where the
value is some invisible reference to the value you actually care about)"
behaves quite differently from pass by value in C, Pascal and others. Java
doesn't copy objects when you pass them to functions. Nor does it pass
references in pass by reference sense.

Java objects are passed using the exact same semantics as Python objects,
and neither pass by reference nor pass by value match that actual
behaviour. Both languages provide an abstraction layer between the internal
implementation details of the interpreter or virtual machine, and the
high-level behaviour of the language.


Stanchfield makes the same mistake with his claim that "Java has pointers",
since of course it does not. The Java language gives you no way of creating
such pointers to arbitrary chunks of memory (or to primitives), no way to
dereference such a pointer if you had one (which you don't), and especially
no way of advancing such (non-existent) pointers to the next record in
memory. To put it another way, not only are pointers not first-class values
in Java, they aren't values at all. There's no way to declare a variable of
type "Pointer to Foo", or equivalent.

So Stanchfield's claim that "Java has pointers" is, again, based on his
conflating of values in the Java language compared to implementation
details of the Java virtual machine. The JVM manages objects via indirect
references to the object, and for that indirection, it may use some form
of "thing which points to another thing":

- C pointers (memory addresses);
- some form of managed reference to a memory location;
- classic Mac OS "handles" (managed pointers-to-pointers);
- or even integer indexes into a giant array, like early 
  versions of Fortran. 

But that hardly means that pointers are a feature of the Java language.



> This holds no matter what 
> kind of object is passed in or what mutable properties it has or does
> not have.

I'm still not getting your point.


-- 
Steven