GNOME Bugzilla – Bug 746156
RFC: new conventions for GObject "stock API"
Last modified: 2018-05-24 17:37:41 UTC
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 GTypeInstances 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, typechecks, 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 Vala 'as' operator (ie: casts, or NULL) 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_case(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.
g_case(GtkFoo, instance) should read "g_cast". Note as well: I considered casts that look like GtkFoo(). While this is technically possible, it would require defining a macro (which is something we are trying to move away from). It would also be potentially very confusing.
I'm a bit worried about having macros/functions going unnamespaced — even though I'm the first to recognise the possibility of collisions to be very small. On the other hand, we thought that foo_bar_get_private() would not collide ever, and look at where that misplaced trust led us. There's also the angle of having a G_DEFINE_OBJECT_TYPE macro match a G_DECLARE_OBJECT_TYPE macro; do we start having FooBar_instance_init, FooBar_class_init, FooBar_parent_class as well?
(In reply to Emmanuele Bassi (:ebassi) from comment #2) > There's also the angle of having a G_DEFINE_OBJECT_TYPE macro match a > G_DECLARE_OBJECT_TYPE macro; do we start having FooBar_instance_init, > FooBar_class_init, FooBar_parent_class as well? Maybe. I don't think that this is hugely important since it's internal-only, but maybe it would be nice to allow for old-style 'gtk_foo_' for these cases. One thing I absolutely do expect to see in time (and I think that it would be extremely helpful for a lot of reasons) is for GtkFoo_get_type() to be the ABI.
(In reply to Ryan Lortie (desrt) from comment #0) > g_typeof(GtkFoo) → GtkFoo_get_type() gtype_of() maybe to not be confusing with a pointless glib redefinition of typeof() ? > to_GtkFoo() > is_GtkFoo() > to_GtkFooClass() > is_GtkFooClass() > get_GtkFoo_class() > get_GtkFoo_interface() Mixing camelcase like that looks wierd to me. Maybe ToGtkFoo() ? > g_cast(GtkFoo, instance) Looks natural, but otoh the point is having something short, and that's longer than other alternatives, like to_GtkFoo().
(In reply to Xavier Claessens from comment #4) > gtype_of() maybe to not be confusing with a pointless glib redefinition of > typeof() ? I'd also consider g_type(). I don't think there is much danger of confusion here, though. I'd really prefer to avoid anything that doesn't start with 'g_'.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1009.