Dan Janowski wrote:
I think this is a vestige of the old fact that there could be two ruby objects that referred to the same XML node. Since I removed that and now there is only a one-to-one relationship between the ruby peer and the XML node, if == is equivalent to equal? and equal? is object identity, then it makes sense to do as you say. Should eql? take on the code of the current ==?
Good point, the new memory model definitely changes things. Currently, the == operator in libxml is an alias for eql?, so there is only one method.
I did a bit of research to understand general ruby conventions. The best write ups I found are:
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/572e8d8b01a7d24e/c5f532d868afab05 http://www.texperts.com/2007/10/16/navigating-the-equality-maze/I like thinking about it this way (taken from one of the comments in the first post):
equal? object identity test
eql? strict equality test, 1.eql?(1.0) is false
(defaults to identity)
== loose equality test, 1 == 1.0 is true
(defaults to identity)
Usually == is the same as eql?, but not always (see the numeric classes
for example).
In theory, you are supposed to override eql? for your own classes and perhaps ==. If you do override eql? you are also supposed to override hash.
FOr libxml, I don't see how a custom eql? methods provides any benefits - why would you compare two xml nodes for equality, and if you did, what does that mean? If the text content is the same, but the document is different, is that still equality?
The big downside is performance, all of a sudden code like this: node1 == node2becomes very slow. In addition, lookups for hash tables or keys that contain nodes as keys also becomes slow.
So, I don't think defining eql? to do a text comparison while defining == to be object identity is a good idea because it would be inconsistent with existing ruby conventions and code. So I propose we remove the overriden eql? method, thereby causing the == operator to default to an object identity test.
Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
