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.

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. 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.

I can provide more detail if necessary.

[1] https://github.com/D-Programming-Language/dmd/commit/867d5479b6d98b23b6c797ee487d1ec1474bee10

-- 
/Jacob Carlborg

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).

Also, why using the Derelict approach and load the library at runtime? The library will always be available and the correct version.

-- 
/Jacob Carlborg

On Thursday, 30 July 2015 at 18:23:21 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).
>
> Also, why using the Derelict approach and load the library at runtime? The library will always be available and the correct version.

I guess it's because I based DerelictCocoa on the old DerelictSDL code you wrote, which was using dynamic binding. It never occurred to me it could also work statically.

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.

On 31/07/15 01:21, ponce wrote:

> 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 see, you're using LDC? Then I recommend you have a look at the Objective-C bridge [1] I created. It has not been updated in a very long time but I think you can use it as a base. Perhaps just update it for D2.

> 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.

The implementation that is currently in DMD head is a very limited implementation that only supports calling instance methods. So no, currently it's not possible to subclass Objective-C classes.

> Not really a problem since class functions do not seem tricky like
> objc_msgSend_*.

Class methods work the same as instance methods. In Objective-C classes are objects themselves.

> 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.

It will call a method in the same way as the Objective-C compiler would do. That means calling obj_msgSend_*.

[1] http://dsource.org/projects/dstep

-- 
/Jacob Carlborg

On 31/07/15 01:05, ponce wrote:

> I guess it's because I based DerelictCocoa on the old DerelictSDL code
> you wrote, which was using dynamic binding. It never occurred to me it
> could also work statically.

Oh, you looked at _that_ code. I thought you found my Objective-C bridge [1].

[1] http://dsource.org/projects/dstep

-- 
/Jacob Carlborg

On Friday, 31 July 2015 at 19:10:05 UTC, Jacob Carlborg wrote:
> On 31/07/15 01:21, ponce wrote:
>
>> 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 see, you're using LDC? Then I recommend you have a look at the Objective-C bridge [1] I created. It has not been updated in a very long time but I think you can use it as a base. Perhaps just update it for D2.

It looks very interesting indeed. Another gem from the D1 days (Cocoa in 2008?).
That said, I don't promise anything because of time scarcity.

On Thursday, 30 July 2015 at 18:21:00 UTC, Jacob Carlborg wrote:
>
> 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. 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.
>
> I can provide more detail if necessary.

Hi Jacob,

I'd be interested by an email or IRC conversation about this. How best to contact you?

I managed to create a NSView subclass classes at runtime and override methods (that involved instance variables for the this pointer).

However a painful thing is for those function returning NSPoint. Some guidance would be welcome!

On 2015-08-14 13:19, ponce wrote:

> Hi Jacob,
>
> I'd be interested by an email or IRC conversation about this. How best
> to contact you?

I guess it depends on the time zones, I'm living in UTC+2.

> I managed to create a NSView subclass classes at runtime and override
> methods (that involved instance variables for the this pointer).
>
> However a painful thing is for those function returning NSPoint. Some
> guidance would be welcome!

Yeah, here comes the tricky part. All methods returning a struct must use the objc_msgSend_stret, EXCEPT if the struct is so small it will fit in registers, then it must use the regular objc_msgSend function.

Also, you always need to cast the objc_msgSend_* function to the correct signature, the signature of the target method.

-- 
/Jacob Carlborg