On 2009-03-22 01:31:28 -0400, "Cristian Vlasceanu"
<crist...@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.for...@michelf.com
http://michelf.com/
