[Ironruby-core] Comparing CLR strings and Ruby strings - a slightly surprising behaviour
Tomas.Matousek at microsoft.com
Wed Mar 4 14:54:05 EST 2009
We can differentiate #inspect on CLR string to print something like i"xxx" ("i" for immutable) or clr:"xxx" ...
We can also implement some default conversions, like to_s where it makes sense.
We can't use CLR strings and make copies since that don't preserve object identity and type (note that we need to also switch between Unicode char and byte). We also need to attach some information with the string (encoding, frozen and tainted flags), so it couldn't be just System.String anyways.
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Meinrad Recheis
Sent: Wednesday, March 04, 2009 11:19 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Comparing CLR strings and Ruby strings - a slightly surprising behaviour
On Wed, Mar 4, 2009 at 9:03 AM, Tomas Matousek <Tomas.Matousek at microsoft.com<mailto: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.
I was thinking the same direction ;). I know, the current design has already been decided and it'd be painful to change it. But I am curious if you thought about the option to actually use clr strings and copy them whenever any muting methods have been called. Would solve the compatibility problem but I guess this might have too bad performance impact on existing library code?
The problem exists only where strings cross the language boundary (from Ruby to C# or vice versa). There would be the option to strictly convert strings into the expected format each time they cross the boundary. I guess this might also be too costly.
Finally a thought about the consequences of the current string incompatibility: I can imagine situations where either clr_strings that "leak" from .Net into ruby library code or ruby strings that "leak" into .NET code might cause bugs which are hard to track down. I was once fooled by the debugger ... thought I got a System.String but it actually was a Mutable string because they exactly look alike. It took some time until I found out what was going on.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironruby-core