Bug : For builtin types, Ruby methods should get precedence over CLR methods

I added the comment below to
http://ironruby.codeplex.com/WorkItem/View.aspx?WorkItemId=1082. Pure
Ruby programs which use names like to_string, get_type, equals, etc will
run into the bug, and the chances of this happening are non-nil. I think
the bug is worth trying to fix for V1 mainly because the proposed fix we
discussed of requiring users to do something like “include clr” could
break a lot of IronRuby apps, and so its better to do the change sooner
rather than later.

OTOH, if the fix is too expensive, we could defer it for later as there
are other bugs which I think people are more likely to run into…

Comments
most recent at top (show oldest at
top<javascript:__doPostBack(‘ctl00$ctl00$MasterContent$Content$ChangeSortLink’,‘’)>)
sbordehttp://www.codeplex.com/site/users/view/sborde wrote Mon at 3:09
PM
This is an issue due to the dual goals of IronRuby of being both Ruby
and a CLR language. The snippet below prints “In FixnumMixin#try_parse”
with MRI, and “1” with IronRuby since Fixnum and System.Int32 are both
one and the same in IronRuby.

module FixnumMixin
def to_string
“In FixnumMixin#to_string”
end
end

class Fixnum
include FixnumMixin
end

puts 1.to_string

This bug could be fixed by changing the default lookup rules for Ruby
builtin types that are also CLR types (not defined in IronRuby.*.dll),
with some explicit action required (eg. requiring the user to open the
Ruby builtin type and do “include clr”) to indicate that the user wants
the CLR methods.

Thanks,
Shri

From: Shri B.
Sent: Monday, May 11, 2009 1:28 PM
To: Tomas M.
Subject: FYI - Opened
http://ironruby.codeplex.com/WorkItem/View.aspx?WorkItemId=1082

A couple of different apps run into this…