On Mon, 2009-06-01 at 12:15 +0200, Jürg Billeter wrote: > On Mon, 2009-06-01 at 05:23 -0400, Yu Feng wrote: > > Think about implementing the GtkBuildable interface(the interface > > itself) with VALA. > > > > If the interface definition is written in VALA to take the advantages of > > Vala, several of the accessor functions have to be supplied in C because > > they selectively chain down to derived implementations based on whether > > the instance is a GtkBuildable or not. Manually looking up the vtable is > > too much for VALA. > > Can you point me to the code where GtkBuildable functions accept > instances not implementing GtkBuildable? From a quick glance at the > code, all the virtual method wrappers appear to contain > Well, I think I misread the code. My bad.
Thank you for pointing this out. However, I skipped the assertions into the next line immediately following the assertion, because that is the line of my interest: if (iface->set_name) (* iface->set_name) (buildable, name); else g_object_set_data_full (G_OBJECT (buildable), "gtk-builder-name", g_strdup (name), g_free); This one can be rewritten with default interface implementations, with an interface base_init function? But more interestingly, I found the very early implementation of GtkBuildable at http://bugzilla.gnome.org/attachment.cgi?id=66080&action=edit + if (iface->set_name) + (* iface->set_name) (buildable, name); + + g_object_set_data_full (G_OBJECT (buildable), + "gtk-buildable-name", + g_strdup (name), + g_free) (notice the else is not there) I am not saying this code is good. But it is interesting, there is a default behavior done by the accessor. no matter the interface is implemented or not this behavior is performed -- and it's opaque to the derived classes. This is the usefulness For example(again might be a bad example), if the object does not even carry the interface, I can use a set_data for the storage instead of failing with an assertion. Because it sounds multi-inheritance and reverts the chaining order, I don't see it natively fit into VALA. The minimal cost of doing this I can imagine will be to literally define extern virtual members as linking against at least the accessor functions. By clarifying this C-linking issue, we won't risk ruining the language or loss anything; will we? - Yu Yu > g_return_if_fail (GTK_IS_BUILDABLE (buildable)); > > Jürg > _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list