[jdom-interest] hashCode() and equals()

[philip.nelson at omniresources.com]

> >So it seems we have some choices
> >1 - break the java hashcode .equals contract
> 
> Unacceptable.

Agreed unless we make namespace implementation is private as you suggest.
This would lead to those very long constructors that we didn't like either
though and dropped some time ago.

> 
> >2 - create a different method that means equal namespace like
> >equalsNoPrefix() and then make equals and hashcode and == 
> all based on
> >prefix and uri
> 
> Unfortunately developers will use the familiar equals() method when 
> they should be using equalsIgnoreprefix(). This will lead to systems 
> like the one Phil Nelson's hypothesized where the prefix matters and 
> the namespace URI doesn't. Also unacceptable.

Hypothesized! Kill the messenger!  actually in a followup I agreed the uri
*is* what matters but that certain implementations may not work.  I have
been working with MSSoap which seems very fussy about things like this. I
guess I'll have to followup and see.

I'm not sure this will affect developers very much as I don't see anybody
comparing namespaces (unless you would write a processor of WSDL or XSLT
documents).  To make it perfectly clear, how about renaming the class to
NamespaceMapping which is what it really is.  Then .equalsIgnorePrefix makes
perfect sense and hashcode, uri and == can all be related to prefix and uri.

> 
> (Note: I'm not convinced that WSDL is such a system, but I don't want 
> to make it easy to create one by accident.)

In both WSDL and as Bob pointed out, in XSLT, there are cases where
comparisons are made where you only know the prefix.  That doesn't mean that
the uri doesn't matter and I never said that the spec reads that way.  If
you need to find the matching definition of an element with
type="xsd:string", you have to take into consideration the prefix, even if
all you do is find the matching uri.

> 
> >3 - make the list returned by getAdditionalNamespaces not 
> live (undead?) and
> >let the chips fall where they may.
> 
> Possible, but unpleasant.

agreed

> 
> >4 - split up Namespace and prefix into separate classes and 
> reinvent the
> >namespace api
> 
> I think the namespace API might need to be revisited one more time. 
> I'm not convinced we need to split up Namespace and prefix into 
> separate classes. On the other hand, perhaps the Namespace class 
> doesn't need to be exposed? Could we plausibly make it package 
> private and just have a public API in Element which exposes the 
> various namespaces and namespace mappings as strings? If so, all the 
> issues about what to do with the equals() method would become moot. 
> We could do whatever we needed internally without worrying about 
> confusing developers.

The signatures do get messy.  People would have to deal with prefixes and
uri's themselves which is ok but I think we are closer to what we want now
than with this approach.