On 2012-12-29 16:38, Chris wrote:
I've heard of this project but always had one problem or another with it. I agree that it is the better solution but I could never make it work properly (probably my own fault).
If you download the pre-compiled alpha it should just work out of the box just as a regular DMD release does.
I agree that bridges are never a good solution (cf. the Cocoa-Java Bridge). I was thinking of a mechanism that isn't bloated, i.e. that only takes what it needs, if that's at all possible. I've succeeded in using ObjC from D (via D's C compatiblity) and it wasn't bloated.
I created basically complete bindings for the Foundation and AppKit frameworks and some others as well. That will cause bloat. I think it's either virtual methods that cannot be optimized away or templates that causing the bloat. The problem with the approached used by DWT/SWT is they only create bindings for what's needed. I guess that's also why it's not as bloated. Then one needs to create binding for each new method one wants to use. That's quite a cumbersome workflow.
My idea is to call D from within a Cocoa application, so that Cocoa is only the interface layer. In the same way D could take care of the business logic on other platforms too and use a C based GUI having a thin "translation" layer between the two. It's not as smooth as having native bindings and a unified API like DWT, wxD etc. but it gives me freedom of choice and flexibility.
Yeah, that would be possible as well.
Btw, how does D fare with mobile phones? Are there issues with 32 and 64 bit? The JavaScript backend (see post above) might come in handy here.
Mobile devices are usually use the ARM architecture, which isn't supported by DMD. You would either need to use GDC or LDC. I think the biggest problem here is that the runtime isn't properly adapted to ARM.
-- /Jacob Carlborg
