DerelictCocoa

[ponce via Digitalmars-d-announce]

On Thursday, 30 July 2015 at 18:21:00 UTC, Jacob Carlborg wrote:
> On 2015-07-30 12:19, ponce wrote:
>> Based on prior Jacob Carlborg'work (AFAIK) and inspired by 
>> DerelictCF
>> (https://github.com/Extrawurst/DerelictCF), DerelictCocoa is an
>> elaborated hack to be able to use Cocoa without Xcode (tm).
>>
>> It does _not_ rely on the recent extern(Objective-C) additions 
>> so I'm a
>> bit unsure how far the compatibility will go in the OS X 
>> lineage.
>>
>> https://github.com/p0nce/DerelictCocoa
>>
>> This is an unofficial Derelict package, so use at your own 
>> risk.
>
> I had a quick look at the implementation. You're not using the 
> objc_msgSend_* family of functions correctly. That's one of the 
> main reasons why extern(Objective-C) was implemented.

Indeed there are things I don't know why it works when it 
shouldn't considering the calling convention. This is more like a 
80% solution until something better can be done.

> I strongly recommend you adapting extern(Objective-C) instead. 
> At least read the commit message [1] for the commit which 
> implements extern(Objective-C). It explains how objc_msgSend_* 
> works.

Unfortunately I'm stuck because OS X shared libraries are not 
implemented in DMD so it may be quite a long time before I can 
use a 2.068 front-end for all this. My target is the currently 
available 2.066/2.067.

> I can provide more detail if necessary.

Thanks for the feedback. I'll start by reading by reading the 
commit in more detail.

Actually I've skimmed it before and failed to understand if it 
allows to subclass ObjC objects. If it doesn't then calling the 
runtime might still be necessary.
Not really a problem since class functions do not seem tricky 
like objc_msgSend_*.

I was also unsure if extern(Objective-C) helps with the runtime 
functions themselves, or rather only dispatch to the right 
runtime function obj_msgSend_*. Or both.