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 > 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. -- henon
_______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
