[ruby-core:45142] Re: [ruby-trunk - Bug #6408][Assigned] DelegateClass#eql? and <=> don't work as expected

On Thu, May 17, 2012 at 12:10:56AM +0900, mame (Yusuke Endoh) wrote:
>=20
> Issue #6408 has been updated by mame (Yusuke Endoh).
>=20
> Status changed from Open to Assigned
> Assignee set to tenderlovemaking (Aaron Patterson)
> Target version set to 3.0
>=20
> Hello, Aaron
>=20
> What do you think about Jeremy's opinion?

I agree with Jeremy's opinion.  I think that changing to is_a? would
probably be be better, but I think my patch should be applied for Ruby
2.0.

> I'm just wondering but why do you want to delegate #eql? ?
> I guess that is because you are inserting Delegate objects
> to a Hash.  Such a code is still dangerous even if the
> patch is applied:
>=20
>   require "delegate"
>  =20
>   class Foo; end
>   class Bar < DelegateClass(Foo); end
>   foo =3D Foo.new
>   bar =3D Bar.new(foo)
>  =20
>   p foo.eql?(foo)  #=3D> true
>   p bar.eql?(foo)  #=3D> true
>   p bar.eql?(bar)  #=3D> false (this returns true with your patch)

Yes, this is the bug I'm trying to fix.

>   p foo.eql?(bar)  #=3D> false (this is NOT fixed)

Yes, you are correct.  I'm not sure how or if we should fix this.

>   h =3D { bar =3D> 42 }
>   p h[foo] #=3D> nil, not 42
>=20
> I think it is difficult to "fix."

It's difficult to "fix" 100%, yes.  However, we can at least reduce our
broken windows. :-)

> The same holds for #<=3D>.
> You should not sort an Array that includes Delegate objects.

I agree.  The problem is that people can create delegate objects, then
feed the delegate object to third party code (say some gem, or some
library in stdlib) and expect it to work.

I think we should either make it work as best we can, or remove
DelegateClass from stdlib.  It should not be a requirement that
DelegateClass users understand how all third party code interacts with
their delegate object (I think).

--=20
Aaron Patterson
http://tenderlovemaking.com/