What does "equals" mean when applied to an instance of Model, MutableModel, TypedModel?

[GoogleCodeExporter]

Is "equals" a part of the contract for the Model interfaces?

If not, we should say that. If it is, we should document that, and add it to 
the test suite.

Original issue reported on code.google.com by eric%tib...@gtempaccount.com on 21 Jun 2011 at 8:32

[GoogleCodeExporter]

No, no, no, no, no!

Model is *stateless*.  The question is meaningless.  That holds for 
MutableModel and TypedModel as well.

The question originally raised (on the mailing list) was as to the equivalence 
of *content models* in *instances*.  Model has *nothing* to do with content 
models, apart from being a tool to explore them.

"Equals" is meaningless when applied to GenXDM's model or any of its 
derivatives.  Any answer is as meaningful as any other.  We should absolutely 
*not* define a meaning for it.  "Behavior is undefined", and therefore, we have 
not defined it.  You can already ask 'instanceof' to distinguish between 
TypedModel, MutableModel, and Model.  In principle, you shouldn't really have 
more than one of each at a time, per bridge (you *can*, now, but it's just a 
way to waste memory), so "==" fully defines the rest of the contract.  Apart 
from object equality, there is no further state in any of these things on which 
a definition of equals() might be based.

Now, the question *does* arise for things like Cursor and Bookmark, which *do* 
have state.  Both Cursor and Bookmark have positional state.  We test equals() 
for Cursor (and bookmark, I think) in the test suite; I'm pretty sure that the 
contract is "the node pointed to is the same".  But possibly I'm 
misremembering, because NodeId.equals(NodeId) is another way of testing node 
equality.

In *general*, the abstractions that a bridge exposes should *not* be the sorts 
of thing for which one *cares* about equality.  Either, like Model, they are 
stateless, or, like Cursor, the state on which some notion of identity might be 
established is volatile, returning different values depending upon the last 
operations completed.

Very, very tempted to mark this not-a-bug.  Why should I not?

Original comment by aale...@gmail.com on 21 Jun 2011 at 10:54

[GoogleCodeExporter]

Hmmm - I looked further at how equivalence is actually being used. The 
Santuariou port test cases need to assert equivalence. The original test cases 
I had did a terrible job of this.

What I can probably do is a much more logical test - see that the type and name 
of the underlying node are equivalent. If they are, then I don't need to care 
whether or not the models are the same or different.

I still think we should document that "equals" has no meaning on this interface 
and its relatives. Changed to a low priority enhancement.

Original comment by eric%tib...@gtempaccount.com on 22 Jun 2011 at 12:35

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Component-Bridges, Priority-Medium, Type-Defect

[GoogleCodeExporter]

All right.  documented at r266.

Original comment by aale...@gmail.com on 29 Aug 2011 at 7:08

• Changed state: Fixed