On Mar 24, 2011 12:26 AM, "Ben Kloosterman" <[email protected]> wrote: > > > Shap wrote > >You are seeing a more fine grained interop and an almost opaque string can wrap / be a .NET string , I was looking more at doing strings the bitc way and sending it to the C or the CLR and then converting to our representation when we get it back. Yes. That's a pretty good summary. I'm looking for a solution where the native invoke layer really only needs to check for well-formedness. > If you want to use CLR strings what about collections , does List<String> fit into the picture? Oh you're just _full_ of cheerful thoughts tonight, aren't you?:-) Actually, with struct methods and type variables we are close. We're missing static members (no big deal), virtual functions, and... inheritance. Which is why I was thinking of just relying on our own lib and sending the strings to the .NET libs rather than operate on them directly. The interesting thing is most of the default lib doesn't use them ( collections) eg string.Join uses sting [] since collections had to be boxed or cast from Object in v1 .. but the same can not be said for more modern libs ( like WCF (comms) /WPF (Gui) ). Why not simply add type classes and regions to C# and see if we can hijack the ecma standards process?:-) May be easier / cleaner ;-) Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
