3 ms·
It's also a symptom of zooming way in on one context and ignoring another, or just general annoying pedantry. From the perspective of an object being passed to
by awj 16y ago
It's also a symptom of zooming way in on one context and ignoring another, or just general annoying pedantry.
From the perspective of an object being passed to a method, Java is pass by reference. No copy of the object is made.
From the perspective of the implementation of methods, Java is pass by value, with the "value" representing any "object" involved being a pointer to that object.
Most of this argument seems to be people choosing one view of this duality and screaming that the other side is stupid and wrong. It's a tedious and annoying thing to see play out (although nowhere near as bad as your average "static vs dynamic typing" debate).
- bena 16y agoI think the difference is somewhat more important than you give it credit for. If Java was truly pass-by-reference, then certain things that are not currently possible would be. It would make some existing code pretty silly frankly.
- awj 16y agoDo you have any good examples? Because I never could come up with a good one. Probably 99% of the reference usage I've seen (all in C++, fwiw) could be about as easily accomplished with pass-by-sharing through pointers. The actual valid uses never seemed worth the nasty copy constructor bugs created by people mistaking reference semantics for pointer semantics. At this point I gave up on "true" references so long ago that I tend to fall in with everyone else and call pointer-based sharing "pass by reference". I suppose I should amend my initial comment to specify that most of the team "pass by reference" is really "pass by sharing (through pointers)", but I'll wait on that until something convinces me that true references shouldn't go the way of dynamic scoping.
- qw 16y agoWhat about primitive variables, like "int"? If Java passed the variable reference (and not a copy), we should be able to modify it
- awj 16y agoYes, if it did that we would be able to modify it (and have those modifications reflected outside function scope). It doesn't, so we aren't. Primitives add complexity to many aspects of Java, calling semantics being one of them. I'd rather they'd went the route of forcing you to always use wrapped primitive types, but it's hard to fault the Java designers on that decision, especially when you consider the context of the time when it was made.