Re: A better cloning mechanism (was: Why not cloneable by default?)

From: Chris Smith (cdsmith_at_twu.net)
Date: 03/30/05 

Date: Tue, 29 Mar 2005 22:19:31 -0700

Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
> I've been struggling to understand your position in this. The following is (in
> part) an attempt to recover the argument that must underlie it. I'm reasonably
> happy that it makes sense, but am less confident that it adequately captures
> your argument -- not least because I'm unable to recover a theoretical
> justification for an emphasis on immutability...

I'm not sure of this either, probably because I don't understand exactly
what you mean in certain cases.

> We want to be able to express the notion of The One True Equality: that two
> "objects" are truly equal if they cannot be distinguished in any way, and so
> that "they" are fully interchangeable (since if we could distinguish between
> them by using one of them in context, rather than the other, then they wouldn't
> be interchangeable, and we'd have a test that could distinguish between them).
> Call that "unconditional equivalence" or just "equivalence" (since the proper
> application of the word "equality" is part of what's under discussion in this
> thread).

That sounds like what I'm looking for, and what I think equals(Object)
does most of the time, except in places where that purpose was lost.
I'd add a caveat, though.

While "One True Equality" is an amusing and flashy phrase, I'd be more
likely to express it as "equality as a java.lang.Object". In other
words, we're looking for a useful concept of equality that applies in
the context of knowing only that you are working with a
java.lang.Object. As others have pointed out, there are other very
useful equalities that are no less deserving of the term; but
Object.equals simply doesn't apply to them because it's a method in
Object.

> Now lets introduce a new concept. Unfortunately I can't think of a good name
> for it that doesn't bring conceptual baggage with it (and precisely the
> conceptual baggage that I'm attempting to understand), so I'll use a bland
> word. Some objects are (or play a role that is) "special", in that no other
> object is allowed to play that role unless it is unconditionally equivalent to
> the first.

Okay. I'm not entirely sure I understand what you mean by "allowed to
play that role", but I'll plunge ahead as if I do.

> Note that being "special" does not in any way imply being immutable.

Depending on your definition of "immutable", I'd argue that being
"special" certainly does imply immutability. Lets define mutability as
the property that, given an object which exists at time T1, its behavior
is defined at time T2 independently of any events that occur between T1
and T2. I have defined immutability in a way that has no dependence on
state, in order to satisfy your issues elsewhere.

Now, if one of two objects A and B is mutable, then I can tell you a
very definite means of distinguishing A and B, which are otherwise
equivalent. Namely:

1. Make some modification to object A that will affect future behavior.
2. Compare that specific behavior of objects A and B.

And voila, I've distinguished them. By your earlier definition of
"unconditional equivalence", which is that there is no test to
distinguish them, A and B are not unconditionally equivalent.

It occurs to me that you might be using some other definition of
"immutable", specifically related to the question of whether any of the
object's fields may change. In that case, I would agree that
immutability is irrelevant. For example, two self-modifying lookup
trees, which allow only lookups and not insertions or deletions, might
be unconditionally equivalent; but they would still be free to re-
arrange the structure of their trees, for example, to make a second
lookup of the same object faster. Then I'd invent some other condition
(call it "changeability", perhaps) and define it as I've proposed for
immutability above, and insist on that instead.

> AFAIK, there are just three ways that we can implement "special"-ness. None is
> perfect, and the three techniques have different trade-offs between them:
>
> a) The VM itself can understand this concept and provide the correct semantics
> directly.
>
> b) We can implement "special" by /imposing/ uniqueness -- using object identity
> to implement unconditional equivalence.
>
> c) We can implement "special" by providing a customised version of the test for
> equivalence, one that understands that two distinct objects can nevertheless be
> considered to be equivalent. In this case you could say that we are
> representing the abstract "special" object by an equivalence class of actual
> objects.

Clearly, a) is not an option, however, since such a thing is not
provided by the virtual machine. That leaves us with b) and c).

I like your wording for c) by the way; it very well captures the nature
of the issue; namely, that any number of Java-language objects may
exist, but that there is still only one conceptual entity in existence.

> I want to emphasise that (at least as I see it) these are /implementation/
> techniques. Different ways of attempting to map our abstract notion of what it
> is to be "special" onto the real behaviour of concrete objects.

In a sense, they are implementation techniques. However, Java does not
provide enough of an abstraction layer to ensure that they really are
hidden within the implementation. Therefore, they are implementations
of the concept, but not "implementation" in the sense of "something a
client need not care about"... at least in Java. I am assuming that's
what you meant.

Incidentally, that latter fact is almost entirely due to Java having
provided an == operator that guarantees a test for reference equality
and a System.identityHashCode() that can be called on arbitrary objects;
instead of both being exclusively inherited as an implementation from
java.lang.Object. I am becoming increasingly convinced, over time, that
this was a mistake on James Gosling's part, though an understandable one
at the time it was made.

> But (b) is still a valid alternative design, even for implementing value
> semantics (it would amount to do doing some sort of interning of the "values").
> And for the wider case where all that's required is "content defined" it may
> even be a better choice (at least if the content is also immutable). In the
> wider still case where we're trying to implement equivalence for "special"
> objects, technique (b) may be the only possible option.

This is, indeed, true. However, it doesn't conflict with requiring
immutable types when overriding equals in Java. Using your technique
b), I don't see why Object.equals would be overridden.

> Anyway, at the end of all that, I can (to a degree) accept that:
> value semantics -> non-mutable -> override (and use) equals()
> but I think it's also important to note that:
> a) that's not the only possible implementation of value semantics.
> b) value semantics is not the only legitimate application of that
> implementation technique.

I don't see where you're getting point b here. Can you explain?

> For instance, Chris Smith mentions the example of Date. If I'm interpreting
> him correctly (and not reading too much into a throwaway remark) he sees Date
> as an attempt to implement value semantics using the technique I've labelled
> (c) (overriding equals() to conceal the difference between distinct objects
> that represent the same date).

Top be picky, my opinion on Date doesn't touch on the issue what it
attempts to do; only what it in fact does. As you say, there are
problems with imposing any interpretation of equals on the current core
API, mainly because it's clear that the authors of the API did not share
any common idea of what equals ought to be. I have my guess about the
oldest use of equals, and one that is confirmed by the majority of its
uses in the API, but there are definitely exceptions. 

-- 
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation