[jdom-interest] Inconsistancy in Namespace.hashCode().
GB/DEV - Philip Nelson
philip.nelson at omniresources.com
Mon Mar 5 06:24:28 PST 2001
> I suppose you can argue that two Namespace objects are not equal if
> they describe different prefixes. Maybe that makes sense, but it
> makes me deeply uncomfortable.
Right, since the namespace class also has a prefix attribute so it's not
really a representation of an xml namespace. What we have is a Namespace +
Prefix class.
>>Hmm... I can see both sides. The counterargument to yours is that for
>>all other objects in JDOM we define equals() as ==, for good reasons
>>that I'll vigorously defend. Thus two <foo/> elements are not equals()
>>unless they're the same element object instance. Same with attributes.
>>Why should Namespace be different?
Yes, this would seem very unnatural to me:
Namespace a = Namespace.getNamespace("prefix1", "http://foo");
Namespace b = Namespace.getNamespace("prefix2", "http://foo");
a == b --> true
a.equals(b) --> false
because from Namespace.equals()
// Compare URIs
if (ns.getURI().equals(uri) && ns.getPrefix().equals(prefix)) {
return true;
}
even if you made both hashcode and equals consistent, I would seem unnatural
for me to say
Namespace a = Namespace.getNamespace("prefix1", "http://foo");
Namespace b = Namespace.getNamespace("prefix2", "http://foo");
and then see a.equals(b) as true.
Perhaps we should
- rename the Namespace class so it's not confused as an api for
representation of an xml namespace (which we don't really need)
- add a method to compare Namespace instances as xml namespaces like
namespaceEquals()
More information about the jdom-interest
mailing list