elfs: (Default)
[personal profile] elfs

Java is Pass-By-Value, Dammit!

Quite possibly the most important article I’ve ever read, because it finally, finally explains to me what Java’s object-passing model is really all about. I’ve never understood it, and now I do: it’s exactly backwards from pass-by-reference, so it’s exactly backwards from the languages with which I grew up. The Object (and derivative) variables are pointers, not references, and calling them references only confuses people who grew up writing C (as I did).

Even more oddly, it explains to me what I’ve never quite understood about Python’s object model, because Python’s object model is exactly the same.   Reproducing the code in the article above in Python creates the same result:

class Foo(object):
    def __init__(self, x): self._result = x
    def _get_foo(self): return self._result
    def _set_foo(self, x): self._result = x
    result = property(_get_foo, _set_foo)

def twid(y):
    y.result = 7

def twid2(y):
    y = Foo(7)

r = Foo(4)
print r.result  # Should be 4
twid(r)
print r.result  # Should be 7

r = Foo(5)
print r.result  # Should be 5
twid2(r)
print r.result  # Still 5

This demonstrates that Python’s code remains pass-by-value, with pythonic “references” in fact being pointers-to-objects. In the case of twid2, we change what the pointer y, which exists in the frame of the call twid2, points to and create a new object that is thrown away at the end of the call.  The object to which y pointed when called is left unmolested.

This is important because it changes (it might even disrupt) the way I think about Python. For a long time, I’ve been using python calls out of habit, just knowing that sometimes objects are changed and sometimes they aren’t.  Now that the difference has been made clear to me, in language that I’ve understood since university, either I’m going to be struggling for a while incorporating this new understanding, or I’m going to be much more productive.

This entry was automatically cross-posted from Elf's technical journal, ElfSternberg.com

Date: 2009-12-07 05:32 pm (UTC)
bolindbergh: (Default)
From: [personal profile] bolindbergh

Reconstructing the thoughts of some dude at Sun back in the nineties:

Pointers are considered harmful, so let's call our pointers references instead.

Date: 2009-12-07 05:40 pm (UTC)
From: [identity profile] elfs.livejournal.com
Remember when I mentioned my habits of thought about Python's "references"? I realized later that the way I think about these things is in terms of (for the example above) the rvalue of old y and the rvalue of new y, that is, that I had created a mental model based upon the notion that the two Y's were different, and Python kept different references counts to the "passed-in Foo" and the "new Foo", and this notion of the argument versus the contained variable allowed me to rationalize how closures work. In fact, it still rationalizes how closures work, it just does so in a clearer way.

I don't think this is so much about the way Sun thinks (after all, Python was doing this years before Java came about) as it is about language confusion. References have always been confusing in C++, but their utility was so much better understood than the lossiness of pointers. Calling their "this thing refers to that thing right now, but if you use this thing as an lvalue for some other thing, this thing will refer to that other thing" a reference doesn't seem a stretch.

Date: 2009-12-07 10:05 pm (UTC)
From: [identity profile] zanfur.livejournal.com
Odd. If you grew up with C, then did anything in C++, then you'd have learned that references were pointers with different semantics: pointers that are auto-dereferenced everywhere except when passed as arguments. Or did you never do anything in C++?

Date: 2009-12-07 10:08 pm (UTC)
From: [identity profile] zanfur.livejournal.com
Yup, that's a good article. I'll have to point others at it.

Date: 2009-12-07 10:32 pm (UTC)
From: [identity profile] elfs.livejournal.com
Oh, and to answer the actual question, yes, I did write quite a bit of C++ for CompuServe, many moons ago. In fact, I came across an old implementation of my Raucous Server (RADIUS (http://en.wikipedia.org/wiki/RADIUS) server with Oracle back-end) and it was written in pretty damn good "core" C++, all things considered.

It was also written Literate, which may have something to do with my not getting lost while writing it.

Date: 2009-12-07 10:27 pm (UTC)
From: [identity profile] elfs.livejournal.com
See, I kinda did it sideways; I did C, then Perl, then C++. By the time I'd gotten to C++, my idea of what a "reference" was, was so screwed up that intellectually connecting them to pointers didn't quite work for me (and believe me, I tried). Probably because Perl "references" worked the way they're supposed to. Anything auto-de-referenced came with a reference count, didn't it?

Thanks, Larry Wall!

Date: 2009-12-07 10:24 pm (UTC)
l33tminion: (Skilled)
From: [personal profile] l33tminion
The Object (and derivative) variables are pointers, not references

That's not true either, though I agree with the statement in the article you reference:

Objects are not passed by reference. A correct statement would be: "Object references are passed by value."

The problem is that Sun won the language war around the word "reference". So what distinguishes a "reference" from a "pointer" (no pointer arithmetic, no explicit dereferencing) no longer has anything to do with what distinguishes "pass-by-reference" from "pass-by-value".

I actually agree with the Java / Python way of doing things in this case, where more than one variable can refer to the same object, but two variables are never secretly the same variable. Although, that design decision works better in Python than in Java, since Python allows functions to have (effectively) multiple return values. (And even better in Lisp which has that plus macros.)

Profile

elfs: (Default)
Elf Sternberg

December 2025

S M T W T F S
 12345 6
78910111213
14151617181920
21222324252627
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 3rd, 2026 03:58 am
Powered by Dreamwidth Studios