GNOME Bugzilla – Bug 632922
unnecessary object method lookup using gtype?
Last modified: 2010-10-26 15:33:29 UTC
Why do we have this loop? http://git.gnome.org/browse/gjs/tree/gi/object.c?id=c68f9b3e0fcf6886acd7675331e96a0b85e2bb76#n307 I can't think of a situation in which it'd be necessary. Unfortunately there is no rationale because the code dates to the initial import: commit c94cbf18983fa5cb47fcfd118b8ff94d71b52361 Author: Lucas Almeida Rocha <lucasr@src.gnome.org> Date: Fri Oct 10 21:37:39 2008 +0000 Initial import. svn path=/trunk/; revision=2
Isn't it for, e.g., GFile instances - the leaf object type isn't introspected - it's a private type - so we have to look at the runtime interfaces of the object to find that out that it exports the GFile interface.
(In reply to comment #1) > Isn't it for, e.g., GFile instances - the leaf object type isn't introspected - > it's a private type - so we have to look at the runtime interfaces of the > object to find that out that it exports the GFile interface. Hmm, right. So I think this is actually a gjs bug though. Take say http://library.gnome.org/devel/gio/stable/GFile.html#g-file-new-for-path which actually returns you a GLocalFile. We know from introspection that that function returns a GFile, but gjs tosses that information away when calling gjs_object_from_g_object. Concretely in the code, gjs_value_from_g_argument has the interface in "interface_type", which it could pass down. So ObjectInstance could have *two* infos in the case where it's being constructed from an interface; the one we know from the GType, and another one that we know it conforms to.
(In reply to comment #2) > (In reply to comment #1) > > Isn't it for, e.g., GFile instances - the leaf object type isn't introspected - > > it's a private type - so we have to look at the runtime interfaces of the > > object to find that out that it exports the GFile interface. > > Hmm, right. So I think this is actually a gjs bug though. Take say > http://library.gnome.org/devel/gio/stable/GFile.html#g-file-new-for-path > which actually returns you a GLocalFile. We know from introspection that that > function returns a GFile, but gjs tosses that information away when calling > gjs_object_from_g_object. > > Concretely in the code, gjs_value_from_g_argument has the interface in > "interface_type", which it could pass down. So ObjectInstance could have *two* > infos in the case where it's being constructed from an interface; the one we > know from the GType, and another one that we know it conforms to. Every GObject has exactly one proxy object for it, that is pinned to it. That means that the proxy has to be constructed and act as the "most derived type" with all interfaces that could possibly be attached. We might get it one time as a GFile and another time later as a GSomethingElse. Not to mention being able to "downcast" an object in Javascript and use it as a derived type based on information that isn't necessarily exported in the static interfaces.
(In reply to comment #3) > > Every GObject has exactly one proxy object for it, that is pinned to it. That > means that the proxy has to be constructed and act as the "most derived type" > with all interfaces that could possibly be attached. We might get it one time > as a GFile and another time later as a GSomethingElse. True. So in this case I think we need a cache mapping GType to List<GIBaseInfo> of interfaces. Anyways my immediate goal was to document the "why" here; I'll add a comment to the code.