RFC: new conventions for GObject "stock API"
Submitted by Allison (desrt)
Link to original bug (#746156)
Description
Now that we have G_DECLARE_*
hopefully entering wider use, and have gotten used to the idea of adding "extra GObject API" via G_DEFINE_AUTOPTR_CLEANUP_FUNC()
, I think we're in a nice place to start adding some new "stock API" that all GTypeInstance
s are expected to implement.
The first thing I hope to do is kill off the one remaining holdout of G_DECLARE_TYPE
: the necessary #define GTK_TYPE_FOO
macro.
My proposal for this will be to have each type declare a function called GtkFoo_get_type()
and add a new macro g_typeof()
that calls it:
g_typeof(GtkFoo)` → `GtkFoo_get_type()
This means that you will see things like:
g_object_new (g_typeof(GtkFoo), ...);
Additionally, I want to define macros based directly on the TypeName
for all of the other "stock API" we have: casts, type checks, get_class
, get_interface
.
I have this set of standard macros in mind:
to_GtkFoo()
is_GtkFoo()
to_GtkFooClass()
is_GtkFooClass()
get_GtkFoo_class()
get_GtkFoo_interface()
and also perhaps some nice new ones:
-
as_GtkFoo()
→ works like Valaas
operator (ie: casts, orNULL
) -
get_GtkFoo_vtable()
→ if we ever move to 'private' vtables (ie: no more padding to keep ABI compat)
We might also consider having some more programmatic-looking macros:
g_cast(GtkFoo, instance)
for example.
The main benefit of this would be to allow us to slowly move away from having to define the GTK_*_FOO
, gtk_foo_
and GtkFoo
versions of everything separately, along with the guessing game that this sometimes brings. This transition really can't be done overnight, and I expect that our existing macros will define both versions of the "stock API" for the considerable future. At some point, though, we can talk about having some (vastly simplified) macros that define only the "new style".
We could imagine for example:
G_DECLARE_TYPE(GtkFoo, GtkWidget)
as being completely sufficient (and same thing for the type define macro).
This is a substantial change to the "feel" of GObject, and I expect there to be a lot of opinions about that. I'm opening this bug now mostly as a request for comments.