[jdom-interest] Namespace.hashcode patch

[Jason Hunter]

philip.nelson at omniresources.com wrote:
> 
> I see Jason just updated this.  So what we have now is
> Namespace ns1 = Namespace.getNamespace("yyy", "http://ffff");
> Namespace ns2 = Namespace.getNamespace("xxx", "http://ffff");
> 
> but
> ns1 == ns2
> 
> I thought what we settled on was that semantic equality, "are these the same
> namespace?" in the xml sense was covered by .equals() only.  "Are these the
> same object?" is covered by == and what a java programmer would expect.
> There is some precedence for this of course.

I'm confused about what you're saying, Phil.  Maybe this will clarify.

ns1 != ns2, because they're not the same object
ns1.equals(ns2), because they can be seen as equivalent
ns1.hashCode().equals(ns2.hashCode()), follows on from above

Of course, now that I'm really thinking about it, if ns.equals() is not
based on == and based just on a uri comparison, that will cause issues
if the getAdditionalNamespaces() method returns a live List.  For
example, you might try (in pseudocode)
remove(Namespace("foo","http://foo")) and really perform a
remove(Namespace("bar","http://foo")).  Since it's legal and not
uncommon to have two namespace prefixes on an elt with the same URI,
this could conceivably come up.

So do we make getAdditionalNamespaces() return a non-live list (breaking
our pattern elsewhere), or do we make Namespace.equals() behave as ==?

-jh-