Java is pass-by-value, Dammit (and so are Ruby and Python, Dammit)

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

by raganwald • 17 years ago

108 73 17 years ago

araneae3• 17 years ago

I've heard that java is both pass-by-value and reference in one class, and then heard that it was pass-by-value only in another. The difference was that the first was at a university that primarily used java, and the second was at a university that primarily taught in C++.

The fact is the usefulness of these concepts depend on what language you're writing in. In java, where pointers aren't explicit, you need to know when you're assigning a variable a memory locale versus a value. In C++, where pointer assignment is explicit, that's not a useful concept, so pass-by-reference has a different meaning.

I honestly think we should come up with a different name for pass-by-reference the way it is used in C++. It's not like people actually write code using pass-by-reference anyway :D.

omnigoat• 17 years ago

I do believe this is why my university teaches Java for one year, then C for the second, before you even get to glance at (C++|Python|Perl|C#|other). I'm a compiler-writer, and we don't need different names - they have well defined meanings. What we need is people to stop misusing them. You've done it yourself, because C doesn't have pass-by-reference. C++ does (ie, references...), but C does not. Stop doing it! Stop misusing those terms! You just read an article that actually spelled it out, and still misused them!

raganwald3• 17 years ago

Redefining terms that have precise meanings into terms that have imprecise meanings based on vulgar precedent is a symptom of a pop culture. Cue Alan Kay quote in 3, 2, 1, ...

mattdawson• 17 years ago

Python, for one, doesn't help to make the matter any clearer. In fact, Python makes it look like pass-by-reference is used, even when it isn't.

For a better explanation than I could ever come up with: http://stackoverflow.com/questions/986006/python-how-do-i-pa...

Just to play devil's advocate: if it looks like a duck and quacks like a duck, why would I call it anything other than "duck"? It may be technically correct to say that (in Python, at least) everything is passed by value. But if it helps someone remember that lists may be altered when passed to a function and that tuples can't, what's the real harm?

Again: devil's advocate.

rlpb• 17 years ago

Meanings are only well-defined in their particular contexts.

fauigerzigerk• 17 years ago

I think the confusion results from the fact that people use the phrase "pass by reference" without ever explicitly stating what the referenced thing is.

In the original sense of the phrase, I believe, that thing was the variable itself in the form of an alias, not the object/value that a pointer variable might be pointing to.

diN0bot• 17 years ago

  def swap(a, b):
    t = a
    a = b
    b = t

  def swap2(a, b):
    t = a['v']
    a['v'] = b['v']
    b['v'] = t

  x = 3
  y = 8
  xx = {'v': x}
  yy = {'v': y}

  swap(x, y) # changes nothing
  swap(xx, yy) # changes nothing
  swap2(xx, yy) # changes 'v' values in xx and yy, but not x or y

dustmop3• 17 years ago

Hence the word "traditional" in the article.

jganetsk3• 17 years ago

Can you write a traditional swap(a,b) method/function in the language?

What about languages that are immutable by default, like Haskell, OCaml, and Erlang? You can't write a swap function. Therefore, are they pass-by-value?

Actually, in OCaml, you can write the swap function.

   let swap a b =
     let temp = !a in
     a := !b;
     b := temp

   let x = ref 3 in
   let y = ref 8 in
   swap x y

But now, you are passing references by value, as Java does. So maybe they are pass-by-value. But, when your language is immutable, pass-by-reference (whatever that would mean), doesn't effect the language semantics. They are pass-by-(it's-moot).

eru4• 17 years ago

Haskell is something like pass-by-name. At least staff only gets evaluated at most once. But it's definitely not pass-by-value, since not everything gets evaluated down to a value.

jganetsk3• 17 years ago

Your argument would get ensnared by that of the original post. If you take the description of Java's passing semantics, and s/object/thunk/ and s/primitive/unboxed value/, you get a perfect description of Haskell's passing semantics.

known• 17 years ago

http://en.wikipedia.org/wiki/XOR_swap_algorithm

jerf• 17 years ago

I've really come to believe that all these terms should be explicitly understood to be domain specific. I can not think of a single term in common use that doesn't have edge cases and other such lacunae when it comes to application to real languages. You name the term, "object orientation", "functional", "reference" vs. "pointer", the distinction really only applies to a given language.

Even the putative "true" definition is usually only the "true" definition in the context of machine language, and something like a true Lisp machine might still end up with no applicable definition for common terms.

(Every time I say this, someone tries to correct me, but it is followed up by someone who then tries to debate the definition being used to correct me. It really is all relative.)

So, in this case, the definition being given for "-by-value" vs. "-by-reference" does hold across a wide variety of imperative languages, but as you point out has no meaning in strictly-immutable functional languages since even inside a given function you can't write a "swap", let alone as a function. The terms only have meanings in certain contexts.

eru4• 17 years ago

In the StateMonad I can write a swap function in Haskell.

jganetsk3• 17 years ago

Not one that, according to the original poster's definiton, would qualify Haskell as a pass-by-reference language.

ionfish• 17 years ago

Indeed; pass by reference / pass by value is an irrelevant distinction in a referentially transparent language.

jp_sc• 17 years ago

Actually in Python is pass-by-reference with lists and dictionaries.

pwmanagerdied3• 17 years ago

Lists and dictionary aren't special, and they aren't pass-by-reference in the sense referred to in the article.

    def foo(my_list):
      my_list = [ "my", "new", "list" ]

Executing this function will not change the value of the list passed to it, it will create a new list and reference it locally. If calling foo(old_list) caused old_list to now contain [ "my", "new", "list" ], then it would be pass-by-reference in the sense this article refers to.

EDIT: To clarify, you can mutate mutable arguments in-place, but you can't change what is being referred to by the identifiers used to refer to these arguments outside of the context of the function, which is what is meant by pass-by-reference in the article.

eru4• 17 years ago

Though my_list.append("blub") does change the outside list. Does this matter?

yason• 17 years ago

You are wrong.

You can modify the original list in your example by having foo() call my_list.append("pwnd!"), for example. You can even use id() to verify that it really is the exactly same object that is visible to the caller and the callee.

Python doesn't pass by reference (in the aliasing variables C++ sense) and it doesn't pass by value (in the functional sense) but rather, it passes references.

Everything is an object anyway but objects aren't copied around. They're just bound or rebound to new variables.

In the above example Python creates new local variables for all function arguments and binds them to the objects passed in as arguments.

If those local variables are assigned to, they're just rebound to point to the new local object while the original variables in the caller code still remain bound to the original object.

kssreeram• 17 years ago

This is a common point of confusion. There are two distinct orthogonal language properties at play here:

1) Variables being references(pointers) to objects.

2) Function arguments being passed by reference or by value.

In Python, all variables are pointers to heap allocated objects, and these pointers are simply passed by value when calling functions.

In C++, it is much easier to understand this distinction as it provides full control to the programmer on both aspects.

jancona• 17 years ago

I think I first saw this debated in comp.lang.java in 1996: http://bit.ly/5XOSey I don't think the arguments have changed much.

eru4• 17 years ago

Long URL: http://groups.google.com/group/comp.lang.java/browse_thread/...

dustmop3• 17 years ago

I reason I think this discussion is ever a problem is because in C++ "pass-by-value" has an extra meaning: that a deep copy occurs. There's no precise term for this, so people started (incorrectly) using "pass-by-reference" to talk about parameters that don't get deep copied. After all, in languages that do it right (Java, Ruby, Python, CL) there's only one parameter passing technique, and therefore no reason to make the distinction.

bff2• 17 years ago

There is a precise term for that and you said it - pass-by-value. Recall that somewhere each language turns into assembly and that in order to pass a value to a subroutine you must either place values into registers or push the data of the object you are passing onto the stack. Passing by value is desirable if you want to make sure that your local value is not modified. This gives the called function the freedom to modify it without worrying about side effects and without worrying about explicitly calling a copy constructor. Pass-by-reference comes from C++'s pass by reference, which is really just some sugar around passing a pointer by value and referencing it with the * operator in the function body (hence reference passing).

I disagree that there is a right or wrong to this - C++ was made to be a generic programming language and thus gives many options to the programmer. If by "do it right" you meant "hide all options except the one most commonly used" okay. Otherwise I strongly disagree with that sentence especially because I use different kinds of "pass-by" whenever I program in C++ and will be using rvalue reference from the C++0x. Different languages suit different needs.

dustmop3• 17 years ago

Well the term is not very precise if the way that you're using it and the way the article is using it are completely different. The article makes it clear that the term "pass-by-value" refers to the fact that the callers' references cannot be unseated by the function call; but it does not mean deep copies are made, like by copy constructor, hence that's why it applies to Java. Allow me to illustrate:

vector<int> numbers; void f(vector<int> args);

Due to C++'s copying, args[0] has a different address than numbers[0], because a deep copy of the vector was made. As the article states, this is not what pass-by-value is referring to, otherwise it would be false that Java / Python / Ruby et al are pass-by-value. So I disagree that the terms are clear, but rather that there is confusion around these terms. As for wanting immutability, it's almost always better for C++ code to write functions not like f but instead like this:

void g(const vector<int>& args);

And apologies for the editorializing, but I do consider this a language design flaw, one inherited from the backwards compatibility for C, which already allowed struct's to be passed (non-pointer) as args and then copied to keep the caller untouchable. It makes C++ code more verbose and more error prone, and is quite difficult for new programmers to grasp.

cturner• 17 years ago

One set of English-language terms are being used by two communities.

1) Those of us who are language users care about use of the language from the perspective of the question, "If this thing gets passed in and I change it, does that change flow back to the calling method." Our perspective of pass-by-reference vs pass by value may originate from experiences learning C. We're probably wrong.

2) This guy is from the community of compiler people. He cares about implementation, and is probably correct.

We need a spoken language abstraction that allows people to discuss the things they care about, and then be able to distinguish between them. The people in the position to cry 'get off my porch' are in the best position to point the rest of us is the right direction.

dschobel3• 17 years ago

It's not an academic point and he's not probably correct.

If you don't understand that it's pass by value of references for non-primitives then you won't understand why your variable x is null after the method call:

  Object x = null;
  fooMe(x);
  //is x null or a Foo?
  [...]

  void fooMe(Object y){
    y = new Foo();
  }

That's fundamental knowledge.

ewjordan2• 17 years ago

If you don't understand that it's pass by value of references for non-primitives then...

Right: pass by value, of references. That's the complete answer, and it's really misleading to say anything else.

I don't think any Java programmers actually have any misunderstanding here, even the worst of them know how this works. What's the problem?

Also, the article tries to use code like this:

  void swap(SomeType& arg1, Sometype& arg2) {
    SomeType temp = arg1;
    arg1 = arg2;
    arg2 = temp;
  }

to prove how different references in C++ are from Java.

But the reason something like that might work in C++ is not that the semantics of parameter passing are different (references cannot be reseated in C++ any more than in Java), but that C++ uses the assignment operator to overwrite the contents of the lhs, and invokes the copy constructor automatically. The true equivalent code in Java works just fine, assuming the copy constructor and set method do the right things (which is a potential pitfall in C++, as well):

  static public void swap(SomeType arg1, SomeType arg2) {
    SomeType temp = new SomeType(arg1);
    arg1.set(arg2);
    arg2.set(temp);
  }

DougBTX• 17 years ago

> 1)

The abstraction of "this thing" getting passed is certainly useful. However, things are clearer if you imagine two variables which happen to be defined in different scopes being set to the same object. Hopefully these questions are trivial to any Java programmer:

If you have two variables set to the same object, and then change the object, are the two variables still set to the same object? Yes.

If you have two variables set to the same object, and then set one of the variables to a different object, are the two variables still set to the same object? No.

dschobel3• 17 years ago

When I was interviewing java devs of all levels few (less than 10%, I'd say) could flat out say "it's pass by value for everything, for non-primitives you're passing references by value" but a lot more (roughly half) could trace the following code correctly.

  Object x = null;
  makeString (x);
  System.out.println (x);

  void makeString (Object y)
  {
    y = "This is a string";
  }

Maybe it's just a disconnect between theory and practice?

moss3• 17 years ago

This.

Java sets up an environment where the parameter passing behavior just isn't surprising. If you've been programming in Java for a little while, it's very easy to have an intuitive feel for how parameters will act, without having to go back to theoretical principles.

Knowing about the theory behind pointers, pass-by-value, and pass-by-reference will still make you a better programmer. But Java's a stronger language for not requiring that knowledge.

kragen• 17 years ago

You're replying to a comment that says "interviewing java devs of all levels... a lot more (roughly half) could trace the following code correctly." That means that the other (roughly) half of the "Java devs" interviewed found Java's pass-by-value behavior to be surprising, even though there are no exceptions to it.

So although Java's behavior is simple and consistent, the parent comment seems to flatly contradict your assertion, "If you've been programming in Java for a little while, it's very easy to have an intuitive feel for how parameters will act." It's also a perfect example of how programming in Java, or in fact any language with a parameter-passing mechanism and mutable variables, does require that knowledge, so your assertion that "Java's a stronger language for not requiring that knowledge" is nonsense.

raganwald3• 17 years ago

This!? Was I asleep when "this" meme swept through the internet? Help me out: what do you mean when you say "This."???

dkarl2• 17 years ago

Yes. Practical programming books usually don't talk about "pass by reference" or "pass by value" anymore, because (as people have pointed out) it's rarely a useful distinction these days, and the correct usage just confuses people because people take pass by value for granted. (C++ programmers basically see references as restricted, syntactically sweetened pointers that are passed by value. And that's almost always good enough.)

I use this as an interview question, too ("Is Java a pass-by-reference or pass-by-value language?") Nobody ever gets it, but I let people choose one of several languages to be quizzed about, and the ones who know this kind of terminology are usually game to pick a more difficult language. I don't hold it against them as long as their explanation of why Java is pass by reference shows a correct understanding of Java parameter passing. But I always set them straight afterwards ;-)

rbanffy3• 17 years ago

I think that, instead of hiring those who correctly figure out what happens in this code, you should hire also those who have strong, almost allergic, reactions against it.

Do you really maintain stuff like this in your codebase?

dschobel3• 17 years ago

No, I simply found it the easiest way to test understanding of pass-by-value vs pass-by-ref.

lg• 17 years ago

  a, b = b, a

Torn• 17 years ago

implicit tuple packing in python doesn't count ;)

_cbsz• 17 years ago

That has nothing to do with the semantics of passing parameters to functions.

    def swap(a,b):
      a,b = b,a

does not work.

va_coder• 17 years ago

The user refractedthought at reddit had the best explanation IMO:

Ok, I think the real losers in this discussion are the ones who fail to see both sides of the issue. We can cherry pick "refrence" definitions if we want, but really the nuts and bolts come down to this: Passing by value means that a copy of the parameter is made when the function is called and any changes to that variable will not be reflected outside of the function. Passing by reference means you pass a pointer to your data (and nothing more) so the function can dereference the parameter and affect data that exists outside of the function.

All non-primitives in Java are implicit pointers, so when you pass one of these into a function, you are passing a pointer (or reference) to data that exists outside of the function. However, the reference itself, as it exists inside the function, can be changed to point toward something else. Essentially, the implicit pointer is passed by value, and that value can be altered without affecting anything outside the function.

So technically yes, you could get away with calling this pass-by-value. However, the spirit of pass-by-reference is maintained for any part of the data that most people care about. The syntax is different from a pass-by-reference in C++, and there's a silly little trick you can do by changing the reference pointer (or silly trick you can't do by changing the pointer outside the function) but for all practical purposes you are doing the same thing.

In my opinion, if you want to insist that Java strictly follows pass-by-value, then I think it has ceased to be a relevant distinction.

scott_s2• 17 years ago

dschobel's comment clearly demonstrates how the distinction between pass-by-value and pass-by-reference in Java is not purely academic: http://news.ycombinator.com/item?id=979799

It's a relevant distinction because it's required to explain code behavior.

rbanffy3• 17 years ago

"it has ceased to be a relevant distinction."

I think this distinction ceased to be relevant in the late 70's...

dkarl2• 17 years ago

So technically yes, you could get away with calling this pass-by-value. However, the spirit of pass-by-reference is maintained for any part of the data that most people care about.

And if there's any time you can afford to be loose about the spirit vs. the "technical" letter of the thing, it's when you're talking to a compiler. Right? I agree with the article. If you don't like the meaning of a technical term with a clear meaning, or if you simply don't have any occasion to use it properly, that's no excuse for repurposing it in the same context to mean something different that leads to confusion.

It's worthwhile to remember that (true) pass by reference isn't just a curiosity from obsolete languages. It's common for people entirely new to programming to expect that function parameters might, or actually do, work that way. The terms are at least useful to explain things to new learners.

In my opinion, if you want to insist that Java strictly follows pass-by-value, then I think it has ceased to be a relevant distinction.

Even if you work only with pass by value languages, you should still respect the terminology. Some mathematicians only work with continuous functions, but they don't say, "Hey, this word 'continuous' would be a lot more useful if we redefined it to draw a useful distinction among the functions we actually work with." So "pass by reference" doesn't mean what you want it to mean and doesn't seem very useful to you. Invent your own terminology. Don't destroy existing terminology by sowing confusion. And that's all you can accomplish -- there are too many people walking around who already know what "pass by reference" means for you to get away with redefining it.

mpakes• 17 years ago

I strongly disagree. Proper terminology is incredibly relevant.

As stated in the original article, pass-by-value and pass-by-reference have well-known definitions within the computer science community. There is no ambiguity here.

When we excuse the lazy use of such terms incorrectly, we hamper the ability to communicate clearly and effectively. Please stop.

The core misunderstanding seems to be a conflation of 'pass a reference by value' and 'pass-by-reference'.

Passing a reference by value != pass-by-reference. The End. Q.E.D.

Pass-by-reference means that the compiler takes a reference of (or, getting a pointer to) the parameter passed in to the function. This is not the same as passing an existing reference (pointer) to the function (by value). Java only allows the latter (primitive types aside).

A side issue is that some developers mistakenly believe that pass-by-value roughly implies a deep copy, and thus that the 'spirit' of pass-by-reference is the avoidance of a deep copy.

I would posit that many C++ functions that operate on object parameters do so via a pointer (a.k.a. reference) passed by value, just as Java does:

  void modify_my_object(MyClass *myObject) {
      myObject.setName("New Name");
  }

  int main(void) {
      MyClass *myObject = new MyObject("A Name");
      modify_my_object(myObject);
      // myObject.name is now "New Name"
  }

This is pass-by-value, and there is no deep-copy happening there.

Just because many developers don't take advantage of (or don't understand the semantics of) pass-by-reference does not excuse ignorance of the well-known definitions of those terms.

0wned• 17 years ago

I think in C++... if you want to be sure the method/function does not alter the data globally and speed is not a concern, then pass by copy. If you want the method to alter the data globally, then pass by reference. If you want speed, but don't want alteration then pass by const reference.

kentosi• 17 years ago

I found this article rather surprising since I come from a primarily Java background.

Do any other languages besides C++ allow this definition of pass-by-reference? The reason I ask is that it seems silly for me to change the way I talk just to satisfy one language that i don't even code in.

And if so, when would it actually be practical to use this? The idea of reassigning a parameter in a function and then having that reassignment affect variables OUTSIDE the function sounds very strange to me (and possible even dangerous).

Xixi• 17 years ago

It used to be very common in Turbo Pascal, where if I remember correctly you had to use the keyword ref.

enjo3• 17 years ago

I disagree with the sentiment that you should simply ignore proper semantics because it's inconvenient. As the article points out, this stuff really does matter.

There are classes of problems that these type of true reference semantics can be quite helpful. In C/C++ the technique is largely used in contexts where you want to return multiple values from a function, as there is no native support for dynamic tuples. Such is the way of statically typed languages.

There are also cases where this type of reference to a pointer magic can really improve the efficiency of the algorithm.

True reference passing is a tool. For those living in dynamic languages (as I do now), not a particularly relevant one. But that doesn't make the distinction any less important.

Java is pass-by-value, Dammit (and so are Ruby and Python, Dammit)

Related Stories