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

[Jason Hunter]

I choose option 3.  It has the advantage that it lets Namespace.equals()
be implemented to compare URIs, and furthermore it avoids an object
creation during a call to getAdditionalNamespaces() on an elt without
any.  This is very helpful because XMLOutputter calls gAN() on every
element during output but 99.9% of elements won't have any additional
namespace decls.

I agree it's unpleasant, but better to have Namespace.equals() be
helpful and output be fast than to worry about that obscure list being
live.

-jh-

Elliotte Rusty Harold wrote:
> 
> At 10:31 AM -0500 6/2/01, philip.nelson at omniresources.com wrote:
> 
> >So it seems we have some choices
> >1 - break the java hashcode .equals contract
> 
> Unacceptable.
> 
> >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.
> 
> (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.)
> 
> >3 - make the list returned by getAdditionalNamespaces not live (undead?) and
> >let the chips fall where they may.
> 
> Possible, but unpleasant.
> 
> >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.
> --
> 
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |                  The XML Bible (IDG Books, 1999)                   |
> |              http://metalab.unc.edu/xml/books/bible/               |
> |   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
> |  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com