|
Pass by value
This brings up the terminology issue, which always seems good for an argument. The term is “pass by value,” and the meaning depends on how you perceive the operation of the program. The general meaning is that you get a local copy of whatever you’re passing, but the real question is how you think about what you’re passing. When it comes to the meaning of “pass by value,” there are two fairly distinct camps:
- Java passes everything by value. When you’re
passing primitives into a method, you get a distinct copy of the primitive. When
you’re passing a reference into a method, you get a copy of the reference.
Ergo, everything is pass by value. Of course, the assumption is that
you’re always thinking (and caring) that references are being passed, but
it seems like the Java design has gone a long way toward allowing you to ignore
(most of the time) that you’re working with a reference. That is, it seems
to allow you to think of the reference as “the object,” since it
implicitly dereferences it whenever you make a method call.
- Java passes primitives by value (no argument there), but objects are passed
by reference. This is the world view that the reference is an alias for the
object, so you don’t think about passing references, but instead
say “I’m passing the object.” Since you don’t get a
local copy of the object when you pass it into a method, objects are clearly not
passed by value. There appears to be some support for this view within Sun,
since at one time, one of the “reserved but not implemented”
keywords was byvalue (This will probably never be implemented).
|