[jdom-interest] Namespace.hashcode patch

[philip.nelson at omniresources.com]

> 
> 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.
> 

You mean because I didn't mention hashcode at all? =8^)

> 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

I assume, and I will be satisfied to be wrong here, that hashcode and ==
have to mean the same thing, an object instance.  .equals() can have a
different meaning though one would avoid it given a reasonable option.


> 
> 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-
>