IronPython doesn't have this problem because they use CLR Strings directly; Python strings map well to CLR Strings. Ruby has mutable strings, and CLR Strings are immutable, so IronRuby strings are different types than CLR Strings.
Comparison of CLR Strings and Ruby Strings should be possible without having to to_s a CLR string ... so this is a bug and on our list of .NET interop things to do. We won't do an auto-conversion of CLR strings to Ruby strings, since a CLR method may return a string that you want to pass onto another CLR method. However, we do convert Ruby strings to CLR strings today. ~js From: [email protected] [mailto:[email protected]] On Behalf Of Meinrad Recheis Sent: Tuesday, March 03, 2009 2:12 PM To: [email protected] Subject: Re: [Ironruby-core] Comparing CLR strings and Ruby strings - a slightly surprising behaviour On Tue, Mar 3, 2009 at 9:46 PM, Thibaut Barrère <[email protected]<mailto:[email protected]>> wrote: Hi, while writing specs for Magic, I noticed that: instance_from(MenuItem, "Hello").text.to_s.should == "Hello" to_s is required to get the assertion to pass. The following will return false: button = Button.new button.text = "Hello" puts button.text == "Hello" So I guess that CLR strings cannot be compared to Ruby strings unless to_s is applied. I have stumbled on this too and was very surprised. This problem does not exist in IronPython (does it? please correct me if I am wrong). The behavior I was expecting is that "on the ruby" side all strings are (or at least behave exactly like) ruby strings, even if they come from .NET and are automatically converted to clr-strings when passed into clr methods. cheers, -- henon
_______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
