.NET on a string

[Michel Fortin]

On 2009-03-22 01:31:28 -0400, "Cristian Vlasceanu" 
<cristian at zerobugs.org> said:

> Another point that I have a hard time getting accross (even to the language
> heavy-weights) is that just because it is easy to represent arrays and
> slices seemlessly IN THE PARTICULAR CASE OF THE DIGITAL MARS BACKEND it does
> not mean it is going to work as smooth and seamless in other systems. The
> .NET backend that I am working on is the case in point. If instead of using
> .NET built-in arrays I craft my own representation (to stay compatible with
> the DMD's way of doing array and slices) then I give up interoperability
> with other languages -- and that would defeat the point of doing D on .NET
> to begin with.

As I read it have no problem integrating with the writing CLR code to 
make D semantics work, but you struggle with seamless compatibility 
with the framework (using .NET predefined classes).

But really, no compatibility? In the D/Objective-C bridge, I have a 
bunch of conversions functions to and from NSArray. You can surely do 
the same in .NET: have the D array type, and the .NET array type, and 
convert from one another when necessary.

Sure, the D/Objective-C bridge isn't a backend based on the Objective-C 
runtime, but to the user it almost is (D and Objective-C objects look 
the same and are interchangeable). If I was pushing that a little 
further and writing a compiler using Objective-C runtime to implement D 
classes, I still wouldn't be able to use NSArray to represents D arrays 
because they have different caracteristics, limitations, and 
behaviours. But I don't see that as a flaw.

That D arrays make different tradoffs than NSArray or .NET arrays isn't 
a problem that should be corrected: it's something that makes D what it 
is as it enables some patterns that wouldn't work otherwise. Sure, 
those different tradoffs makes things harder to bridge with arrays 
defined in some existing frameworks (both Cocoa and .NET), but if they 
make things easier and nicer inside the D language I'm all for keeping 
them.

So when using the D/Objective-C bridge, there are two array types and 
you use the one most appropriate for the job. And you can convert from 
one to the other when necessary.

Perhaps you should look at means of easying the conversion process when 
passing D arrays to functions expecting .NET arrays instead of fighting 
to unify two different array concepts into one.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/