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','')>)
sborde<http://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 Borde
Sent: Monday, May 11, 2009 1:28 PM
To: Tomas Matousek
Subject: FYI - Opened
http://ironruby.codeplex.com/WorkItem/View.aspx?WorkItemId=1082
A couple of different apps run into this...
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
