proposal: expose ObjC API to gomobile bind programs

[elias...@gmail.com]

Hi,

I've posted a proposal (and implementation) of an extension to Gomobile such that Go programs can access ObjC (and iOS) APIs directly:

https://github.com/golang/go/issues/17102

It is the ObjC equivalent of my previous proposal for Java:

https://github.com/golang/go/issues/16876

 - elias

[Adam Strzelecki]

Thumbs up! However there's no mention how the memory management gonna be handled? Manually - I mean I need to [... dealloc] for each [.. alloc] like in old-school ObjC, or some kind of ARC is included/or planned in your patch? And how Go memory can interop with ObjC memory/instances. Anyway I think this deserves some explanation in your proposal.

Finally I want to ask if the classes and methods are resolved compile time or runtime?

Nevertheless the whole idea is nice, because it makes possible to have native Go UI wrappers for macOS/OS X (hopefully).

Regards,

-- Adam

[elias...@gmail.com]

On Tuesday, September 20, 2016 at 11:36:18 PM UTC+2, Adam Strzelecki wrote:

Thumbs up! However there's no mention how the memory management gonna be handled? Manually - I mean I need to [... dealloc] for each [.. alloc] like in old-school ObjC, or some kind of ARC is included/or planned in your patch? And how Go memory can interop with ObjC memory/instances. Anyway I think this deserves some explanation in your proposal.

Nothing about the memory handling changes with this proposal: gomobile keeps internal records of the ObjC instances that passes into Go and keeps them live until there are no more references from Go. Furthermore, every generated ObjC wrapper is compiled with ARC so reference counting works the same way as regular ObjC classes.

 

Finally I want to ask if the classes and methods are resolved compile time or runtime?

They are resolved at compile time. When you run gomobile bind, the output of clang -cc1 --ast-dump is parsed to discover ObjC classes, protocols and their methods. Then, Go wrappers are generated for your code to call into.

 

Nevertheless the whole idea is nice, because it makes possible to have native Go UI wrappers for macOS/OS X (hopefully).

That's also my hope.