[Ironruby-core] Comparing CLR strings and Ruby strings - a slightly surprising behaviour

Thibaut Barrère thibaut.barrere at gmail.com
Wed Mar 4 03:54:07 EST 2009


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
<Tomas.Matousek at microsoft.com> 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: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
> Sent: Tuesday, March 03, 2009 10:09 PM
>
> To: ironruby-core at rubyforge.org
> 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: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Meinrad Recheis
> Sent: Tuesday, March 03, 2009 4:25 PM
> To: ironruby-core at rubyforge.org
> 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
> <Tomas.Matousek at microsoft.com> 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
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


More information about the Ironruby-core mailing list