D/Objective-C Bridge

[Michel Fortin]

On 2007-09-18 03:19:22 -0400, Anders F Björklund <afb at algonet.se> said:

> Is this based anything on the earlier similar work called "Docoa" ?
> 
> http://dsource.org/projects/docoa

I took a look at Docoa a little while ago, but no, nothing is based on 
it. I've written it all from scratch. I think the only thing we have in 
common (and which could be harmonized) are the Objective-C runtime 
declarations for types and functions (converted from C headers).

>> The goal is mostly to make it workable for writing Mac OS X 
>> applications using Cocoa. The bridge allows D objects to be 
>> instantiated from nib files, with outlets and actions being connected 
>> as any Cocoa programmer would expect.
> 
> The program seems to be using "objc_msgSendSuper_fpret", which I'm
> not sure if it even exists ? At least that's what I googled up on:
> http://lists.apple.com/archives/Objc-language/2006/Jun/msg00012.html
> alias objc_msgSendSuper objc_msgSendSuper_fpret; // workaround ?

Ah, I see you're on Intel. :-) Basically, because of the architecture, 
the runtime on Intel use a different function to send messages with 
floating-point return values. objc_msgSendSuper_fpret seems to be 
missing in Apple's headers for the runtime (so I didn't put it in), but 
without it you don't have any mean to call a method with a floating 
point return value.

I'd suggest you try adding this instead:

	version (X86)
	double objc_msgSendSuper_fpret(objc_super* superContext, SEL theSelector, ...)

after function definintion objc_msgSendSuper_stret in objc/runtime.d.

This is the logical choice for the name of the function, but if this 
doesn't work, I'd suggest tracing with the debugger into a real 
Objective-C program to check. That's something I can't do on my machine.

>> There are still a few round corners, missing thread-safty, performance 
>> issues and possibly the lack of Intel support (I don't have an Intel 
>> Mac to test).
> 
> The project compiled (after the above), but the adder doesn't... add.
> So it seems to be missing some interaction with the action binding ?
> It does send the event though, so it might just be "a cocoa thing".
> (i.e. printing out the value to the console in the controller works)

It's missing its floating point return value. :-)

>> There is also much to be written: the bridge requires writing a wrapper 
>> class for each class in the Cocoa framework we want to make available. 
>> It's pretty easy thanks to all the templates, but it's still 
>> time-consuming.
> 
> How do you intend to get around the copyright / distribution problem ?

Not sure yet. Perhaps it should be based on GNUStep instead of Cocoa 
(while still making sure it works with Cocoa). Or perhaps we should 
just ask Apple, they seem pretty cool with language bridges these days 
(they're bundling PyObjC and RubyCocoa with Leopard I've heard).

> The way it was originally planned for Carbon was with auto-conversion.
> So that you'd download a program you could run on "your own" headers...
> Possibly something like SWIG, with auto-generation plus some patches.

I'm not sure about autoconversion. What's interesting when writing 
manually the wrappers is that you can shorten the method names. Things 
wouldn't be too bad for methods like this one:

	[dict setObject:object forKey:key];
<=>
	dict.setObjectForKey(object, key);

although I think binding it to opIndexAssign (like I did) makes more sense.

But look at what it would do for NSAlert:

	[NSAlert alertWithMessageText:msg defaultButton:default 
alternateButton:alt otherButton:other informativeTextWithFormat:info];
<=>
	NSAlert.alertWithMessageTextDefaultButtonAlternateButtonOtherButtonInformativeTextWithFormat(msg, 
default, alt, other, info);

Erk. Sure, things could be patched, but I have the feeling a lot of 
patches are going to be needed. I wonder how Apple did their bridge 
with Java... oh, I see: that method just isn't there.

Which makes me think that, performance-wise, it may be a good idea to 
leave a few methods unbridged too.

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