Why not cloneable by default?

[Thomas G. Marshall]

Chris Uppal coughed up:

[a very late reply. I don't know if anyone's still interested. But
in case anyone is, I've left the stuff I'm replying to untrimmed]

....[snip lonnnng but appropriate post]...


Phew. You guys are making me dizzy.

As I try to boil down some of what Chris Smith is saying, there is a
statement paraphrase that might go something like this (Chris---holler if
I've botched this) :

If there are two mutable objects, then how
can they be equivalent if they can clearly
change.

Now, in english it is quite possible to provide enormous, yet perfectly
honest, dissertations on how unconditional equivalence means one thing, and
equivalence as defined by java has not reached that, and how anything called
"equals()" must mean "equal for all time", parry, thrust, parry, thrust...

English allows for non linear conversations. It is very hard to do a point
by point argument without some point raising definitions that confuse other
points. You end up with either circular arguments or endlessly bifurcating
trees of meaning. Both have happened here.


--
I've seen this a few times--Don't make this mistake:

Dwight: "This thing is wildly available."
Smedly: "Did you mean wildly, or /widely/ ?"
Dwight: "Both!", said while nodding emphatically.

Dwight was exposed to have made a grammatical
error and tries to cover it up by thinking
fast. This is so painfully obvious that he
only succeeds in looking worse.

 

[elliott.coates]

Chris Smith coughed up:

Mutability comes about because it conflicts with certain important
characteristics of objects that are "equal" to each other; namely,
that they can't become unequal later on. I could put it differently,
though. Basically, equals(Object) should only be overridden in
classes that desire value semantics instead of object semantics.
Since such classes must be immutable anyway, it naturally follows
that mutable classes should not override equals(Object)

Why should we not be able to compare the values of 2 or more instances
of the same class?

Or even in the case of mutable class types, why should we not be able
to compare those *parts* of classes in an inheritance/composition class
hierarchy that have parts that are initially in common when 1st created
and might later mutate?

Elliott

 

[Chris Smith]

Why should we not be able to compare the values of 2 or more instances
of the same class?

Or even in the case of mutable class types, why should we not be able
to compare those *parts* of classes in an inheritance/composition class
hierarchy that have parts that are initially in common when 1st created
and might later mutate?

I think that this conversation (the equals branch, anyway) has mostly
run its course, though I intend to respond to Chris when I get the time.
Nevertheless, I'll say once more that the issue isn't whether you should
be allowed to compare such things. Clearly, you can. The questions
that this brings up, though, are:

1. What does "the value of an instance" really mean? Can you define it
in useful terms without knowing which class you are dealing with? If
not, then it is wrong for Object to define an "equals" method that
performs that (undefined without context) type of comparison. It is
quite possible for subclasses of Object to define *other* operations
that perform that comparison, though.

2. Does that type of comparison fit with the general use of Object's
equals method in the core API and other common parts of Java? This has
no good answer, because the usage of equals in the core API is not
consistent.

A variety of positions are possible on those questions. However, no one
is saying that you should not be able to compare the current state of
objects; but you possibly shouldn't be using Object.equals to do it.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation