After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 627241 - add G_DEFINE_[ENUM|FLAGS]_TYPE
add G_DEFINE_[ENUM|FLAGS]_TYPE
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gobject
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2010-08-18 08:33 UTC by Christian Persch
Modified: 2018-05-24 12:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
a proposal (18.66 KB, patch)
2012-08-28 05:13 UTC, Matthias Clasen
none Details | Review
beter patch (5.45 KB, patch)
2012-08-29 02:26 UTC, Matthias Clasen
none Details | Review

Description Christian Persch 2010-08-18 08:33:09 UTC
As requested in bug 449565 comment 17.
Comment 1 Matthias Clasen 2012-08-28 05:13:22 UTC
Created attachment 222608 [details] [review]
a proposal
Comment 2 Dan Winship 2012-08-28 13:07:20 UTC
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.
Comment 3 Matthias Clasen 2012-08-28 14:21:38 UTC
(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.
Comment 4 Matthias Clasen 2012-08-29 02:26:15 UTC
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.
Comment 5 Emmanuele Bassi (:ebassi) 2013-12-13 14:34:46 UTC
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.
Comment 6 Allison Karlitskaya (desrt) 2013-12-13 15:12:59 UTC
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).
Comment 7 Emmanuele Bassi (:ebassi) 2013-12-13 15:32:31 UTC
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?
Comment 8 Allison Karlitskaya (desrt) 2013-12-13 19:00:49 UTC
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.
Comment 9 GNOME Infrastructure Team 2018-05-24 12:36:10 UTC
-- 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.