comparing objects
in [Ruby]
|
From: Wilson Bilkovich on 5 Jun 2010 19:18 On Sat, Jun 5, 2010 at 4:09 PM, Robert Dober <robert.dober(a)gmail.com> wrote: > I must have made a stupid mistake in my example code, however, this is > no reason to mess with #eql? and #hash, Be warned. > In that case I stick with Robert's advice: Do not use Array#&, even > MPing Array with something like #intersect_by would be preferable. Implementing this behavior with your own object types is the whole point of the Ruby core API. I find myself struggling to understand the mindset that would prefer re-opening Array and adding something over using the already-there-for-a-reason Enumerable and Array interfaces. Using eql? and hash is not 'messing with' them, unless you don't take the time to understand your tools.
From: Robert Dober on 6 Jun 2010 13:05 On Sun, Jun 6, 2010 at 1:05 AM, Ryan Bigg <me(a)ryanbigg.com> wrote: > Robert Dober wrote: >> On Sat, Jun 5, 2010 at 8:55 PM, Rein Henrichs <reinh(a)reinh.com> wrote: >> <snip> >>> The Array#& operator, like its siblings, uses the #hash and #eql? methods of >>> the objects it compares. These must be the same for objects you want to be >>> considered equivalent. >>> >> I must have made a stupid mistake in my example code, however, this is >> no reason to mess with #eql? and #hash, Be warned. >> In that case I stick with Robert's advice: Do not use Array#&, even >> MPing Array with something like #intersect_by would be preferable. >> > > Wow. Sorry, I am just stunned by this, so no sugar coating for you > today. > > Array#& is a perfectly legitimate method to be using for the purpose of > finding the intersect of two Array objects, which it seems what the OP > wanted to do originally. > Did I say you should not use Array#&??? I do not think so. I said, do not overload Object#hash and Object#eql? for the purpose to use Array#&. And if I was not clear enough I will try again: It will brake any client code that uses your objects as hash keys. Thus you override #hash and #eql? if you want that behavior only. But yes, using Array#& with different object comparison semantics seems a bad idea to me. Please bear in mind that there is no reason to assume that OP has the kind of experience to assume the side effects present (He would not have asked the question in that case). Cheers Robert -- The best way to predict the future is to invent it. -- Alan Kay
From: Robert Dober on 6 Jun 2010 13:23 On Sun, Jun 6, 2010 at 1:18 AM, Wilson Bilkovich <wilsonb(a)gmail.com> wrote: > On Sat, Jun 5, 2010 at 4:09 PM, Robert Dober <robert.dober(a)gmail.com> wrote: >> I must have made a stupid mistake in my example code, however, this is >> no reason to mess with #eql? and #hash, Be warned. >> In that case I stick with Robert's advice: Do not use Array#&, even >> MPing Array with something like #intersect_by would be preferable. > > Implementing this behavior with your own object types is the whole > point of the Ruby core API. > I find myself struggling to understand the mindset that would prefer > re-opening Array and adding something over using the > already-there-for-a-reason Enumerable and Array interfaces. Really? What do we want to do? We want Array#& work with a tailor made comparision. I accept that attitude, although I would not recommend it. Now I would expect that the responsibility for changing the semantics of an Array method should be in the Array class, or a module closely related to class. As Array#& needs to invoke client object's methods, we have to change those. And reality is that Hash methods invoke those same client methods. Thus I would not say that #hash? and #eql? are already here for the reason you stated. > > Using eql? and hash is not 'messing with' them, unless you don't take > the time to understand your tools. I agree that was bad style from my side, sorry. However I maintain that the context does not really justify their modifications as the semantic impact is much greater than wanted, unless of course OP wants hashes to believe exactly as they would after the aforementioned modifications. Cheers Robert -- The best way to predict the future is to invent it. -- Alan Kay
From: Robert Klemme on 6 Jun 2010 16:53 On 05.06.2010 16:41, Robert Dober wrote: > On Sat, Jun 5, 2010 at 2:35 PM, Robert Klemme > <shortcutter(a)googlemail.com> wrote: >> On 05.06.2010 00:35, Anderson Leite wrote: >>> Before >>>> we can provide solutions we have to know what problem must be solved. >>> I have a list of objects that came from database and another list of >>> objects extracted from a xml. I need the elements who are in both lists. >>> >>> >>> Then...I thought to compare objects overriding the == method like Marcin >>> Wolski wrote. There is another solution ? >> If all objects you are dealing with implement #eql? and #hash in a way to be >> suitable for that comparison then using #eql? is the most straightforward >> approach. > Not #eql?, #== please. Why? Array#& uses #eql? - as Hash lookup methods do, too. $ ruby19 -e 'class C;def eql?(x)printf "eq %p\n",x;false;end;def hash;0;end;end;[C.new] & [C.new]' eq #<C:0x10028284> Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Ryan Bigg on 6 Jun 2010 17:47
Robert Dober wrote: > On Sun, Jun 6, 2010 at 1:05 AM, Ryan Bigg <me(a)ryanbigg.com> wrote: >>> MPing Array with something like #intersect_by would be preferable. >>> >> >> Wow. Sorry, I am just stunned by this, so no sugar coating for you >> today. >> >> Array#& is a perfectly legitimate method to be using for the purpose of >> finding the intersect of two Array objects, which it seems what the OP >> wanted to do originally. >> > Did I say you should not use Array#&??? I do not think so. Let me refresh your memory: "In that case I stick with Robert's advice: Do not use Array#&," -- Posted via http://www.ruby-forum.com/. |