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
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
