On Tue, Mar 9, 2010 at 10:02 PM, Eric Northup <[email protected]> wrote:
> Not sure if this matters but there's at least one magic property of
> [MSCorlib]System.String which I think also applies to the JVM's String:
> there is a guarantee that string literals (which have type
> System.String) will be interned by the runtime and so can be compared
> via eq (and the instance method String.Intern() is also mildly but
> similarly magic).
Yes. This is how the per-object lock managed to leak across the domain
boundary. :-)
> It seems to me like interoperability is a compelling reason to use the
> runtime-provided strings, appropriately wrapped and tamed. Otherwise
> you'll end up allocating and copying strings all over the place at the
> BitC <--> {CLI, JVM} interface.
I agree. The issue at hand is what to do with the "char" type. There
is some need for sanity checking strings at the interop boundary, but
aside from that I see no reason why CLI/JVM strings can't be used
directly.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev