Hi guys, thanks for the discussion. I really understand how tricky this can be from an infrastructure point of view. I raised this point because I pretty much believe the question is going to come over again and again from newcomers. My feeling (although I understand what's happening under the cover) is that it breaks the POLS a bit, and that people using IronRuby for the first time could find it somewhat "flaky" (aaah, it's an interop thingy, ok).
Just my opinion - if it stays the same, a red bold entry in the FAQs will be useful :) In the code itself, I don't believe this kind of comparison will be so common, and a .to_s will not necessarily hurt. For people that write tests/specs though, it clutters the code quite a bit. So when running tests, I think my solution will be to patch System::String to avoid cluttering the specs with .to_s calls. I'll share it here if I come to something that works for me. cheers and thanks for the discussion, appreciated, -- Thibaut On Wed, Mar 4, 2009 at 9:03 AM, Tomas Matousek <[email protected]> wrote: > Apart from being mutable they also carry an encoding along. Ruby string is > basically a resizable byte array with an encoding. > > > > CLR strings are actually closer to Ruby symbols than to Ruby strings. So we > have two options on the Ruby side: either to implement the same set of > methods Symbol has or a subset of String methods that don’t mutate the > string. Since Ruby doesn’t provide many useful methods on Symbol it might be > better to choose the latter. > > > > Tomas > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Jimmy Schementi > Sent: Tuesday, March 03, 2009 10:09 PM > > To: [email protected] > Subject: Re: [Ironruby-core] Comparing CLR strings and Ruby strings - a > slightly surprising behaviour > > > > (This is my understanding of the problem, so Tomas please correct me if it’s > wrong … I wasn’t involved in the initial decision). > > > > The “mutableness” of a string is the defining distinction, so we don’t make > CLR string act like a Ruby string in cases, because it won’t allow mutation. > This is the same reason we can’t easily allow Ruby methods to operate on CLR > strings, because mutating methods won’t work (chomp!, etc). So rather than > only supporting part of the Ruby methods on CLR strings, you have to > explicitly ask for one or the other. > > > > In practice, I haven’t felt much pain by this when hosting IronRuby. The > hosting layer can make sure to convert any CLR string into a mutable string, > and any strings pulled out of IronRuby code can be turned into CLR strings > by the way Tomas showed below. > > > > ~js > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Meinrad Recheis > Sent: Tuesday, March 03, 2009 4:25 PM > To: [email protected] > Subject: Re: [Ironruby-core] Comparing CLR strings and Ruby strings - a > slightly surprising behaviour > > > > Ok, the Execute<T> is convenient enough. In my opinion the highlighted C# > code represents a potential interoperability pitfall and will need to be > documented well. > > On the ruby side, I think there are no technical limitations to achieve > ruby's string behavior even if the underlying object is an immutable clr > string. What do you think? > > -- henon > > On Wed, Mar 4, 2009 at 12:24 AM, Tomas Matousek > <[email protected]> wrote: > > We don’t plan to make the highlighted code work. However we are going to > make this work: > > > > string s = engine.Execute<string>(“’hi’”) > > > > and also this works: > > > > string s = engine.Execute(“’hi’”).ToString(), > > > > although in this case you need to take care of null. > > > > The difference is that unlike Execute, Execute<T> invokes an explicit > dynamic conversion on the resulting type. You can achieve the same using > engine.ObjectOperations.ConvertTo<string>(engine.Execute(“’hi’”)). > > > > Tomas > > > > [...] > > In addition to that, it would also be great to have automatic type > conversion on the .NET side too. I'd expect to be able to assign a string > pulled out from the interpreter to a C# string without the need to call > ToString(). For example, > > string s = engine.Execute("'hi'") as string; > > Currently s would be null because the dynamic cast to System.String fails. > > > > _______________________________________________ > Ironruby-core mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
