Re: [Vala] Crazy Vala callback behavior

[Matthias Klumpp <matthias tenstral net>]

Hi!

2011/12/18 Abderrahim Kitouni <a kitouni gmail com>:
> [...]
> I implement an internal class in Vala,
> > which defines the following callback:
> >   public signal Results request_whatprovides (uint filters, uint
> > provides, [CCode (array_length = false, array_null_terminated = true)]
> > string[] search);
>
> AFAIK, signals with return values aren't supported in Vala. Another
> important thing you didn't mention is what is result (is it a class, a
> struct).
It is a GObject-derived class. (I thought this was clear when I wrote
it's a pointer to a GObject)
If return values aren't supported, shouldn't valac emit a
warning/error-message, so I don't even try to do this?

> And since you're talking about a callback, maybe you meant
> delegate instead of signal.
Yep, I didn't think of using a delegate before! This solved all issues
now, thanks! (Sometimes the easiest solution is the best)

> > [...]
> I think you really mean a delegate, and if so, your callback should have
> the arguments (guint filters, guint provides, gchar** search, gpointer
> user_data), and return a Results* if Results is a reference type, and
> have the arguments (guint filters, guint provides, gchar** search,
> Results* result, gpointer user_data) if Results is a struct.
>
> >  xy_request_whatprovides_cb (BackendProxy *sender,
> >                               PkBitfield filters,
> >                               PkProvidesEnum provides,
> >                               gchar** search,
> >                               gpointer user_data)
>
> Why are you using different types for the arguments? You should probably
> have bindings for the library that is used by both you app and the
> loadable module.
I used different parameters to work around some problems before. But
using different types isn't really a problem here.
Thank you for your delegate hint :P Really stupid that I haven't
thought about this before!
Cheers,
   Matthias