Re: SAX2 Namespace Support
David Brownell wrote: > > Brett McLaughlin wrote: > > > > David Brownell wrote: > > > > > > David Megginson wrote: > > > > > > > > In principle (the principle of least surprise), it's very bad > > > > behaviour for two objects to be == in C++ or equals() in Java if any > > > > of their publicly-accessible fields differ. Think of sets, for > > > > example. > > > > > > Actually, it's quite common for nontrivial objects that equals() only > > > involve a subset of the visible properties. It's probably even typical > > > in applications I've worked with. > > > > I agree with David B. in theory, but David M. (gee, that's confusing...) > > in practice. I think that equality, and assumptions about equality, > > have some side effects. For example, if two objects compared through > > equals() return true, then I expect to be able to use the object > > interchangeable. > > You expect wrong; sorry. Look at the spec for java.lang.Object.equals(); > it guarantees quite a few properties (reflexive, symmetric, transitive, > consistent, ...) but NOT substitutability. (Use "==" or some specialized > method for that.) No... read again: > > I agree with David B. in <<theory>>, but David M. (gee, that's confusing...) > > in <<practice>>. I know what equals() is supposed to do. However, if we took a poll on who knows what it is supposed to do, you wouldn't get many "ayes" :-( I know this is defensive programming. However, if you _know_ a lot of people are going to make a mistake, shouldn't, as a good developer, you try to avoid cases where you _invite_ that mistake? I don't argue with your reading of Sun's API. In fact, I agree (which is why I always implement equals() and hashCode() in my custom classes). However, I know how people think (try writing a book to the masses, and making assumptions about what people know - not pretty!), and am forced to acknowledge that. > > > So I think equals() isn't a good idea; however, something like <code>if > > (name1.sameNamespace(name2))</code> or something equivalent (not the > > best example, but you get the idea) doesn't offend my eyes.... for what > > it's worth. > > Were there to be a Name class that couldn't be used as a hashtable key to > get the expected effect, then it'd be unusable. You're suggesting that, > in effect. Only to a certain degree; the example was just to say if we want to provide an equality test for this specific purpose, than I think a better choice (one that helps people, but doesn't hurt us) would be to use a more intuitive name than equals(). But yes, using equals() or any related function carries with it some side effects such as hashtable key considerations. -Brett > > - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format