Re: Newbie: cloning a Number
Daniel Pitts wrote:
I would consider an object to be immutable if no behaviour could change
its semantic value after instantiation.
Now you're stuck with defining "semantic value" in terms
a compiler can recognize. Good luck ...
As for behavio[u]r: Can you even define *that* precisely?
For example (chosen with malice aforethought): Is the ability
of an object to suspend a thread part of its behavior? That
is, is the state of an object's lock part of its behavior? If
so, *all* objects are mutable, and trivially so: All you need
do is synchronize on the object, and bang! its behavior w.r.t.
other attempted synchronizations is altered. Its state has been
changed, has been "mutated," and so it is "mutable."
Well, you might argue that the lock does not contribute to
the "behavior" of an object. That seems to me an untenable
position: If thread T1 can synchronize on an object and then
twiddle its thumbs for twenty minutes, surely that state of
affairs can influence the behavior of thread T2 (to wit, by
inhibiting T2's forward progress for some fraction of twenty
minutes). If T2 prints the time of day before and after a
stretch of code that synchronizes on the object, surely T1's
holding of the lock influences T2's behavior, does it not? From
the perspective of any thread attempting to synchronize, the
object's locked or unlocked state changes its observable behavior.
I'll repeat my earlier assertion: "``Immutable'' is a slightly
fuzzy concept." The harder you try to pin it down, the fuzzier it
becomes. It squirms off the microscope slide, it Heisenbergs
itself away to Never-Never Land, and eventually it inhabits the
same realm as Potter Stewart's famous opinion: "I shall not attempt
to define [obscenity] but I know it when I see it." Legal eagles
may be comfortable with such non-answers, but people who realize
that they must predictably arrive at ONE or ZERO are not.
--
Eric Sosman
esosman@acm-dot-org.invalid