ianprime0509
Exporting classes for use from C
One of Zig's strengths is its interoperability with C, in both directions. The current functionality of this library allows users to consume GObject code written in C or C-compatible languages, but it doesn't immediately offer a good way to export GObject code written in Zig back to the broader ecosystem.
Perhaps some comptime magic could be used to export a type and its functions using C naming conventions? For bonus points, somehow generating the C macros associated with custom types in a header file would make interoperability even more seamless.
I'm thinking of a similar idea, not sure if they are same.
Currently zig-gobject is a binding, so running this project needs goject.
I'm thinking of a pure zig implemented "gobject protocol" / or "gobject interface", so the code base is purely zig, but it is compatible to gobject interface, from binary level, just like Microsoft's COM interface, which is language independent.
If we have a zig implemented gobject system, it will be easy to extend gobject app or eco-system in zig. It will also be benificial to zig as well: zig does not have a object system or programming patterns, following gobject might be a good idea.
Thanks for the input and suggestion! To expand on what this issue is aiming at, I'd like to be able to generate an interface and glue code to interact with GObject-based code written using this project (e.g. with gobject.ext.defineType). To compare this goal with Zig's own functionality, the current functionality of this project is basically "enhanced zig translate-c for GObject"; what this issue is proposing is to also offer an "enhanced -femit-h for GObject".
As for the idea of a pure Zig "GObject protocol" as you describe it, if I understand it correctly, I think the missing piece for doing that with this project is an implementation of GObject itself in Zig (the underlying runtime and its functions for type registration and management). That would certainly be an interesting idea, although probably further in the future, as it would likely be a lot of work to replicate all the functionality that GObject (the C implementation) currently provides.