Re: Pass by reference or value?
getsanjay.sharma@gmail.com wrote:
On May 18, 1:11 am, Eric Sosman <esos...@acm-dot-org.invalid> wrote:
As for manipulating the objects whose references are passed:
The method or constructor can *always* manipulate any object it
has a reference to, understanding that "manipulate" need not
imply "modify." There's no need to make special exceptions for
String or other so-called immutable classes; calling str.length()
or str.hashCode() is just as much a "manipulation" as calling
any other method. (Indeed, hashCode() changes the internal state
of a String object the first time it's called on that object: by
computing and caching the hash code!)
How does and in what context is "manipulation" different from
"modification"? Or is it that the functions called on the immutable
object lend to its "manipulation"?
"Immutable" is a fuzzily-defined concept. For example, it
is common to say that String is immutable, even though some of
its internal state can change after the String has been created
(as by hashCode, for example).
One might say that the object is still "immutable" if the
changes to its internal state are not "visible" outside the
object itself. In the case of hashCode, one might argue that
there is no way for the caller to detect whether the returned
value was freshly-computed or was cached. And yet, there might
in fact be a way to do so: If you made very careful timings of
hashCode on a very long string, you might be able to observe
that the first call took longer than subsequent calls; does
this amount to a difference in behavior?
For that matter, it is in fact possible to "change" an
existing String object in such a way that, say, charAt(0)
returns different values at different times. (You use what
Patricia Shanahan calls "reflection abuse" to find the char[]
array underlying the String, and then you change the values
of the array elements.) So it turns out that that String is
only immutable in the face of "normal" operations -- which
really says only that String cannot be changed unless you
change it! By that definition, *every* class is "immutable:"
just label any value-changing operations as "abnormal."
But let's go ahead and restrict ourselves to "normal"
operations. Can we get visible changes in behavior from
our immutable Strings?
// synchronized ("string")
{
Thread t = new Thread(new Runnable() {
public void run() {
synchronized ("string") {
System.out.println("in thread");
}
}
});
t.start();
System.out.println("thread started");
t.join();
System.out.println("thread finished");
}
Clearly, the code's visible behavior -- its output -- depends
on whether the first line is or isn't commented out. What is
the difference? In one case the second thread can run to
completion, and in the other it cannot. What is the reason for
this difference? It has to do with whether the String "string"
is or isn't locked -- that is, it has to do with the state of
the supposedly immutable object "string". A change in the state
of "string" produces a change in the behavior of the program; how
can we keep straight faces while we talk about this state change
and still say "immutable?"
Immutability is a useful concept, but hard to pin down with
exactitude. "I know it when I see it," as Justice Potter Stewart
said of another notion; the fact that he could do no better is
evidence for the existence of things that seem easy to understand
but prove hard to define. I believe "immutability" is one such.
--
Eric Sosman
esosman@acm-dot-org.invalid