Bug #2224
closedlib/delegate: operator delegation
Description
=begin
The operators ==, =~, !~ are forwarded by Delegate. I presume the operators != and ~, new in 1.9, have simply been forgotten?
As for eql? and hash, this is probably intentional. I am still curious as to why, since this can yield surprising results (at least to me):
a = "foo"
a1 = SimpleDelegator.new(a)
a2 = a1.dup
h = {}
h[a] = :bar
h[a1] = :bar
h[a2] = :bar
h # ==> {"foo"=>:bar, "foo"=>:bar, "foo"=>:bar}
=end
Updated by mame (Yusuke Endoh) over 14 years ago
- Assignee set to matz (Yukihiro Matsumoto)
- Target version set to 1.9.2
=begin
Hi,
The operators ==, =~, !~ are forwarded by Delegate. I presume the operators != and ~, new in 1.9, have simply been forgotten?
Agreed. Yugui, do you permit to fix this?
As for eql? and hash, this is probably intentional. I am still curious as to why, since this can yield surprising results (at least to me):
Me too. Matz, is this really intentional?
I wrote a patch, but I cannot anticipate the impact.
At least, make check and make test-rubyspec seem to pass.
diff --git a/lib/delegate.rb b/lib/delegate.rb
index f366091..e35d3b2 100644
--- a/lib/delegate.rb
+++ b/lib/delegate.rb
@@ -117,7 +117,7 @@
class Delegator < BasicObject
kernel = ::Kernel.dup
kernel.class_eval do
- [:to_s,:inspect,:=~,:!~,:===,:<=>].each do |m|
-
[:to_s,:inspect,:=~,:!~,:===,:<=>,:eql?,:hash].each do |m|
undef_method m
end
end
@@ -168,6 +168,15 @@ class Delegator < BasicObject
self.getobj == obj
end -
def !=(obj)
-
return true if !obj.equal?(self)
-
self.getobj != obj
-
end
-
def !
-
!self.getobj
-
end
-
This method must be overridden by subclasses and should return the object¶
method calls are being delegated to.¶
--
Yusuke Endoh mame@tsg.ne.jp
=end
Updated by marcandre (Marc-Andre Lafortune) over 14 years ago
- Assignee changed from matz (Yukihiro Matsumoto) to marcandre (Marc-Andre Lafortune)
=begin
=end
Updated by marcandre (Marc-Andre Lafortune) over 14 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
=begin
This issue was solved with changeset r28309.
Marc-Andre, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
=end