On 17 October 2012 09:35, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com" target="_blank">doob@me.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2012-10-16 19:57, Ethan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm just going to throw it out there that you don't actually need to<br>
touch Objective-C at all. Cocoa/Foundation/all those Objective-C<br>
interfaces sit on top of something known as Core Foundation, which are C<br>
APIs. The pointers used by Core Foundation can generally be used as<br>
Objective-C objects of the same type as well.<br>
</blockquote>
<br></div>
That's not entirely correct. Most of the types in Core Foundation are a toll free bridge to the corresponding Objective-C types in the Foundation framework. But all the GUI related classes, i.e. AppKit, are not available in the same way.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It would be handy to have a D binding to all the Core- libraries on OSX.<br>
I might do that myself when I get my Mac if such a binding doesn't<br>
already exist. The book should be equally applicable for iOS as well,<br>
but last time I was in iOS land I was still a newbie to the whole OSX<br>
programming thing.<br>
</blockquote>
<br></div>
If you're going to write GUI applications on Mac OS X you need to interact with the Objective-C frameworks. The reason for this is that, as stated above, AppKit is only available from Objective-C and you really need to be able to create your own Objective-C classes and subclasses.<br>

<br>
There are two ways to interact with Objective-C<br>
<br>
* Create an Objective-C/D bridge<br>
* Make D binary compilable with Objective-C<br>
<br>
The Objective-C/D bridge would use the Objective-C runtime functions defined in C to interact with Objective-C. Every time an object is passed over the bridge it needs to be encapsulated or de-encapsulated. Another problem is the code/template bloat. A Hello World application will be around 60MB in size. This has already been done:<br>

<br>
<a href="http://www.dsource.org/projects/dstep" target="_blank">http://www.dsource.org/<u></u>projects/dstep</a><br>
<br>
The other approach would be to make D binary compaitable with Objective-C, that is, provide extern (Objective-C) declarations. This would generate basically the same code as the Objective-C compiler would, but with the nice syntax of D instead of the horrible syntax that Objective-C is. This would also allow you do create bindings to Objective-C classes, methods and functions just as with C.<br>

<br>
The problem with this approach, it's a lot of work to modify the compiler. But that has already been done as well:<br>
<br>
<a href="http://michelf.ca/projects/d-objc/" target="_blank">http://michelf.ca/projects/d-<u></u>objc/</a><br>
<br>
This fork of DMD isn't ready yet (there's an alpha available) and there hasn't been any changes made in over a year. If I recall correctly, Michel Fortin said he hasn't got the time now to work on this. It also the problem with always playing catchup with the upstream version of DMD.</blockquote>
<div><br></div><div>It occurred to me last night, I think almost all the work to get OSX running is actually already done in the iPhone drivers. You might be better off to copy the iPhone files, and adapt that to OSX. Ethan seems to think iPhone and OSX are almost identical.</div>
</div>