comparing objects
in [Ruby]
|
From: Benoit Daloze on 6 Jun 2010 18:03 [Note: parts of this message were removed to make it a legal post.] Hi, Just wanting to add my thoughts about this (I made a thread about this a few months ago). I searched a bit and concluded this: Array methods using comparison - with #hash and #eql? &, |, uniq(!), - - with #== include?, (r)assoc, count, delete, (r,find_)index (please say me if I forgot one) I think Array methods should never have to look at #hash and #eql? methods. I suppose this is done for performance. I think this should change, because: - it violates POLS - it can make unexpected behavior because you defined #hash and #eql? , for objects which should not need that (when you manage objects in an Array, you do not expect to need to think about Hash's keys). - it is not consistent with other Array's methods PS: Rein: I saw your implementation of #hash. I think to "add one" is useless, because #eql? is always used (so even if #hash was always the same, it would work). It could maybe speed up a bit, but only if you have a lot of comparison of User and User's instances, which is very unlikely.
From: Rein Henrichs on 6 Jun 2010 20:38 I agree that using eql? and hash for some methods is surprising. I would not mind seeing this changed to at least just eql?. == seems too general for the semantics of these methods. On 2010-06-06 15:03:30 -0700, Benoit Daloze said: > PS: Rein: I saw your implementation of #hash. I think to "add one" is > useless, because #eql? is always used (so even if #hash was always the same, > it would work). It could maybe speed up a bit, but only if you have a lot of > comparison of User and User's instances, which is very unlikely. Without the + 1, User.new('').hash == User.hash. I don't like the existance of a bug even if I don't yet have a way to exercise it in my code. -- Rein Henrichs http://puppetlabs.com http://reinh.com
From: Rein Henrichs on 6 Jun 2010 20:59 I think that this is now well outside the scope of the original topic, so I will briefly say that implementing a semantically appropriate #eql? and #hash on your class is the way to make them behave as expected when used as hash keys and with methods like Array#&, honoring the principle of least surprise. It is as normal (and useful) as implementing #== for simple comparisons. I hope that other Rubyists that may stumble upon this thread will take Robert's FUD with a grain of salt and will feel free to determine the usefulness and any potential dangers of implementing #eql? and #hash -- along with other Ruby idioms like #each (for Enumerable) and #<=> (for Comparable) -- on their own. An ounce of critical thinking is better than a pound of dogma. -- Rein Henrichs http://puppetlabs.com http://reinh.com
From: Wilson Bilkovich on 10 Jun 2010 09:41 On Sun, Jun 6, 2010 at 9:00 PM, Rein Henrichs <reinh(a)reinh.com> wrote:> > I hope that other Rubyists that may stumble upon this thread will take > Robert's FUD with a grain of salt and will feel free to determine the > usefulness and any potential dangers of implementing #eql? and #hash -- > along with other Ruby idioms like #each (for Enumerable) and #<=> (for > Comparable) -- on their own. An ounce of critical thinking is better than a > pound of dogma. > Let me be clear, People of the Future: implement eql?, ===, and hash on your own classes as appropriate. Doing so is the proper way to allow your code to interact with other libraries and coders. Even if your code lives in isolation, ensuring proper semantics via these methods prevents a class of tricky bug that your successors may have to deal with.
From: Robert Dober on 10 Jun 2010 09:59
On Thu, Jun 10, 2010 at 3:41 PM, Wilson Bilkovich <wilsonb(a)gmail.com> wrote: Even if > your code lives in isolation, ensuring proper semantics via these > methods prevents a class of tricky bug that your successors may have > to deal with. Hmm? Would you care to show an example where overloading those methods (#eql? and #hash) is needed to ensure proper behavior? I am willing to learn. But I am not willing to accept this statement as such. Cheers R. -- The best way to predict the future is to invent it. -- Alan Kay |