[Ironruby-core] Comparing CLR strings and Ruby strings - a slightly surprising behaviour
meinrad.recheis at gmail.com
Wed Mar 4 14:18:55 EST 2009
On Wed, Mar 4, 2009 at 9:03 AM, Tomas Matousek <Tomas.Matousek at microsoft.com
> 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
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