[jdom-interest] Namespace.hashcode patch

[philip.nelson at omniresources.com]

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

Oh boy...  The only thing we have determined for certain is that there
aren't many cases for comparing namespaces.  Those we know about are
internal to the api.  People have a strong feeling that .equals should work
the way it does now.  Changing what == means violates basic java meaning
(but may speed up some namespace operations which now have to do .equals).
Hashcode pretty much has to uniquely identify an instance for the reasons
you point out.  

> Would a better approach be to use 
> two maps?  One mapping
> prefix -> Namespace and one mapping URI -> Namespace?  

We actually started with this and eventually the other mapping atrophied
away.

> Isn't that what 
> remove(Namespace("foo","http://foo")) actually means;
> that you're removing the prefix, not necessarily the 
> namespace from the element?

Yes and no.  Yes there may still be another namespace with the same uri.
Calling remove on the List is really the opposite of
addNamespaceDeclaration.

> 
> That's probably too much work at this stage.  Could we make 
> .equals() mean == again
> and add a .matches() or a .equalsIgnorePrefix() or something 
> to the Namespace
> interface to test for "xml equality"?  It's a kludge but it 
> would work and not
> impact the rest of JDOM much.

Since use cases for comparing namespaces are so few I would hope we could
just make the current api work.  I think we had an uneasy truce with the
current api before the change to hashcode.  Aside from correctness
arguments, did you have another problem with the hashcode implementation? I
really don't see how we can have hashcode relate to the uri only and expect
it to work in a List.