Re: [Vala] Problems with virtual extern methods.

[Yu Feng <rainwoodman gmail com>]

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