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 561360 - do not fail for not-found GTypes
do not fail for not-found GTypes
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-11-18 13:47 UTC by Philipp Schlesinger
Modified: 2015-02-07 16:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Bug-561360-If-we-can-t-resolve-parent-class-use-G.patch (6.61 KB, patch)
2009-02-05 20:30 UTC, Colin Walters
none Details | Review

Description Philipp Schlesinger 2008-11-18 13:47:30 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...
Comment 1 Øyvind Kolås (pippin) 2008-11-18 15:02:17 UTC
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.
Comment 2 Colin Walters 2008-11-18 18:38:46 UTC
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.
Comment 3 Dan Winship 2008-11-18 19:01:05 UTC
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.
Comment 4 Johan (not receiving bugmail) Dahlin 2009-01-13 15:50:09 UTC
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

Comment 5 Colin Walters 2009-01-13 16:13:43 UTC
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.
Comment 6 Colin Walters 2009-02-05 20:30:07 UTC
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 7 Johan (not receiving bugmail) Dahlin 2009-02-05 20:57:00 UTC
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.
Comment 8 Philipp Schlesinger 2009-02-05 21:01:29 UTC
The patch works for the original issue reported in this bug.

Best regards,

   Philipp
Comment 9 André Klapper 2015-02-07 16:54:35 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]