On Sun, Jun 6, 2010 at 1:18 AM, Wilson Bilkovich <wilsonb / gmail.com> wrote:
> On Sat, Jun 5, 2010 at 4:09 PM, Robert Dober <robert.dober / 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