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 629080 - add G_TYPE_FLAG_FINAL type flag to make un-subclassable (final) types.
add G_TYPE_FLAG_FINAL type flag to make un-subclassable (final) types.
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gobject
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2010-09-08 15:52 UTC by Colin Walters
Modified: 2018-05-24 12:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Colin Walters 2010-09-08 15:52:38 UTC
<ebassi> <unknown>:: Warning: Clutter: (GLibObject)BindingPool: Failed to find class structure for 'BindingPool'
<walters> oh
 well...
<ebassi> clutter-color.h:144: Warning: Clutter: clutter_param_spec_color: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip)
<walters> the reason we warn is mainly because the lack of convention for interfaces
<ebassi> (it returns a GParamSpec)
<walters> right now we check "Iface" and "Interfaces"
 ebassi: well you can (skip) the latter one
<ebassi> it's not an interface
<walters> right
<ebassi> ClutterBindingPool is a final class
<walters> i can not warn but...i don't quite like having the lack of a class structure => final
<ebassi> then a bunch of errors for missing wrappers
<ebassi> walters: well, that's the current convention shared among gobject-based libraries
<walters> can we change it? =)
<ebassi> heh
 I knew you would say that
<walters> well
<ebassi> it's just - the instance struct is already opaque; if I add another opaque struct for the class, then I have to document it
<walters> i'm not opposed to implementing "no class" => final, just negotiating here
<ebassi> and it's just another symbol that doesn't do anything
<walters> okay, i'll remove the warning
<ebassi> it might even lead people to believe that they can get the pointer to the class structure using G_TYPE_INSTANCE_GET_CLASS()
 (which they can, but it wouldn't do them any good)
 it's not that I'm generally opposed, but it would have some pushback
<walters> what about adding G_TYPE_FLAG_FINAL or something?
<ebassi> would require having a G_DEFINE_FINAL_TYPE() and depending on glib master + 1
 though it would be nicer
<walters> hiding the class structure doesn't actually prevent you from subclassing, would it?
<ebassi> it does
 because you can't use the class inside your own vtable
 since the compiler doesn't know the size of the struct
<walters> hmm, oh right
 though gobject wouldn't complain if you just picked a large class size, right?
 we're just relying on the lack of sizeof(FooSomeClass) being unknown?
<ebassi> yep
<walters> i could add an annotation?
 FooSomeClass: (final) ?
<ebassi> you could read clutter sources and do it manually, I guess
 yeah, a new annotation would probably be better
 (and maybe ask gobject devs to think about a flag for final classes as well)
<walters> i'll look into adding the GType flag too
 but at least this way we avoid a dep on gobject+1
 thanks for the discussion
Comment 1 Christian Persch 2010-09-08 16:58:12 UTC
<walters> hiding the class structure doesn't actually prevent you from
subclassing, would it?
<ebassi> it does
 because you can't use the class inside your own vtable
 since the compiler doesn't know the size of the struct

Just BTW, subclassing without public instance and class structs *is* possible, and used e.g. by a11y. You just use g_type_query() to get the sizes of the parent type's instance and class structs (and use instance and class private data to extend).
Comment 2 Emmanuele Bassi (:ebassi) 2013-08-26 10:42:59 UTC
I think we established that the best practise in GObject-based libraries to create "final" types is to just provide the typedefs for both instance and class structures in the header file.

if we want to have a G_TYPE_FLAG_FINAL then we should re-assign this bug, as it's not really something introspection-related.
Comment 3 Matthias Clasen 2015-09-13 06:11:16 UTC
One thing G_TYPE_FLAG_FINAL might be nice for is faster type checking.
Comment 4 GNOME Infrastructure Team 2018-05-24 12:44:52 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/342.