GNOME Bugzilla – Bug 561360
do not fail for not-found GTypes
Last modified: 2015-02-07 16:54:35 UTC
An example: GeglBuffer, a public class is a subclass of GeglTileHandler, a private class and fully opaque. g-ir-scanner gives: WARNING: DELETING node Buffer: "Failed to resolve GType name: 'GeglTileHandler'" and g-ir-compiler fails with: ** WARNING **: Entry 'Buffer' not found aborting...
GeglBuffer in the GEGL API is completely opaque to an application compiled against GEGL, the parent classes are implementation details that can and will change. The actual internal hierachy of types is: GObject GeglTileSource GeglTileHandler GeglBuffer Subclassing GeglBuffers outside the GeglBuffer source tree is explicitly not permitted, knowledge of the parent types i not provided in the source and is not needed since gegl_buffer_get_type is all that is needed from C to instantiate an object. GeglTileHandler does have one property and if the other properties of GeglBuffer are to be considered public this one might be as well, the "source" property (which has a G_TYPE_PARAM_OBJECT). The GeglBuffer API would still work without any of the properties exposed though. /pippin - paranoid about making APIs public.
Hm, this came up before didn't it? And maybe the refactored dumper grew the same bug again. Well I'm not sure if I wrote this down before, but I'm pretty unhappy with supporting private superclasses. Right now the fact that it exists is known through g_type_parent which is public API; conceptually we're adding a much more fleshed out reflection system which is just making it more obvious. Now that my unhappiness is on the record =) practically speaking I am OK with a hack for this, it's fairly similar to the hack for skipping properties (I can't find the bug to hand). I'll see if I can create a patch.
It seems like usually if a parent type is missing, it means you forgot to include either a source file or a library dependency when scanning, doesn't it? (Or is this distinguishable from that case?) If there's any chance this would cause things to *accidentally* be omitted, it seems like it would be better to require an annotation explicitly saying that the type is supposed to be missing.
I'm with Colin. If a class is public the whole inheritance chain should also be made public for obvious reasons. It doesn't matter that it's not included in a public header, you can still traverse using g_type_parent etc to get the type and traverse it's properties etc. I mean, if you consider a superclass private and then rename/refactor you'll still break what I consider completely valid code. To me there are two ways of solving this bug: - Create a shallow parent class. It'll be included in the gir - Modify Gegl itself and include it in the headers
The way private superclasses work in the Java object model is that the private class is exposed in reflection, but you can't by default call any methods from the private superclass or access any of its fields (short of setAccessible()). I think I incorrectly stated before that private superclasses were invalid in the Java model, but that's not true. So as a third option, we could implement the equivalent by supporting a (private) annotation on classes, and this would cause the methods/properties/signals of that class to not appear in the gir/typelib. However there would be a <class> entry for it.
Created attachment 128036 [details] [review] Bug-561360-If-we-can-t-resolve-parent-class-use-G.patch This patch just hides the parent entirely, which is what seems to be desired.
Comment on attachment 128036 [details] [review] Bug-561360-If-we-can-t-resolve-parent-class-use-G.patch Looks good, perhaps rename the parent to FooHiddenBaseClass or something so we know what it is.
The patch works for the original issue reported in this bug. Best regards, Philipp
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]