GNOME Bugzilla – Bug 627241
add G_DEFINE_[ENUM|FLAGS]_TYPE
Last modified: 2018-05-24 12:36:10 UTC
As requested in bug 449565 comment 17.
Created attachment 222608 [details] [review] a proposal
Comment on attachment 222608 [details] [review] a proposal does anyone actually register enum and flags types by hand? >+ * A helper macro for use with #G_DEFINE_ENUM_VALUE(). s/VALUE/TYPE/ >+ * Here is an example: >+ * |[ >+ * G_DEFINE_ENUM_TYPE(GPasswordSave, g_password_save, other code examples use standard glib style (space before the paren) >- >+ the vast bulk of this patch is whitespace changes, which should probably be committed separately.
(In reply to comment #2) + > > the vast bulk of this patch is whitespace changes, which should probably be > committed separately. Sorry about that. It wasn't intentional.
Created attachment 222700 [details] [review] beter patch We ended up fixing pango enums without using this macro, so I'm just parking this here for now.
I've been using something pretty much like this in at least three projects (two at work, and one I'm working on), by now, so I really think we should land it. inflicting glib-mkenums on projects without many enumerations is really not worth it.
Minorly against this on account of the intense number of relocations... We should figure out a way to do this without, and then adjust the macros accordingly (as well as mkenums).
if we add new API to reduce the relocations it's going to be easier to fix the macros, as opposed to fix all the glib-mkenums template files or the Makefiles of every project using glib-mkenums command line arguments. I assume that we could start by introducing a new pair of functions: g_enum_type_register_static() g_flags_type_register_static() (which would actually match with g_boxed_type_register_static() in terms of naming policy). do we have a bug for that already?
I don't think we have a bug for it already... something that Matthias has been thinking about for a while, though. My concern is that the macros may put us into a bad position in terms of what we can do with the API... we've seen many times in the past that we've had to adjust new macro APIs based on demands of the underlying implementation... if we change how this works in GObject we may well end up with our shiny new macro API unable to adhere to the new conventions. That said, as you suggest, this would be used only for "small" cases where mkenums is not worth it, so maybe the damage of the relocations is not high... I still think we should figure out what to do about the relocation situation first, though.
-- 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/330.