GUI program on Mac OS in D?

[Jacob Carlborg]

On 2017-12-14 14:56, mrphobby wrote:

> Also, it feels a bit awkward to implement the callback handling methods 
> as static methods, with the "self" and SEL arguments. Would have been 
> nice if it was possible to use instance methods.

That's currently not possible. The "self" and SEL arguments are required 
because that's how Objective-C methods are implemented under the hood.

> After thinking about it for a while I guess it could work with one 
> static dispatch method that maps selectors to specific instance methods. 
> So when callbacks are made from Objective-C they are made to this one 
> static method, which would then call the right method on the class.

It's not possible to use instance methods because:

* Interfaces can only have final instance methods
* The function needs to have C linkage, which a D instance method cannot 
have
* It's not possible to use classes because then the compiler would 
complain about missing methods when Objective-C methods are specified 
without any body

> I'm still struggling with D syntax, so here's some pseudo code:
> 
> class AppDelegate {
>     static var methodMap = {}    // Maps selector name to methods
> 
>     static void handleCallback(AppDelegate self, SEL sel, ...) {
>        var method = methodMap[sel];
>        self.call(method, va_list);      // Call the method with args 
> (not sure if possible in D)
>     }
> 
>     void applicationDidFinishLaunching(NSNotification notification) {
>        // Normal instance method here
>     }
> }
> 
> Now, you would also need a registration step somewhere that sets up the 
> selectors to use, perhaps in a static constructor that is run when 
> AppDelegate class is used for the first time.
> 
> I hope this makes sense. Just throwing out some ideas :)

No, that would not work. Several years ago I created an Objective-C 
bridge [1], which allowed a syntax similar to above:

class AppController : NSObject
{
     void foo() {}
     mixin ObjcBindMethod!foo;
}

The bridge basically wrapped an Objective-C object inside a D object, 
resulted in two objects for each object instead of one. That bridge 
turned out to be a failure, vary complicated, huge amount of template 
instantiations and bloat from a lot of virtual methods that could not be 
removed. A simple test application with a window and a button resulted 
in a 60 MB executable.

DIP43 is the next step in the evolution after the bridge and it's a much 
better approach. When DIP43 is done, or at least has made some more 
progress it will be much simpler.

Please keep in mind that all this is work in progress, that's why it is 
as complicated now as it is.

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

-- 
/Jacob Carlborg