Re: [Vala] MarkupParser binding

[Abderrahim Kitouni <a kitouni gmail com>]

Hi,

2009/12/5 Michael 'Mickey' Lauer <mickey vanille-media de>:
> How can we fix the MarkupParser binding?
>
> Apart from the anonymous callbacks, which needs fixing upstream, it
s/the anonymous callbacks/all it's C-isms/ ;-)
> still doesn't quite work, as the delegates complain about their missing
> target. How can we fix that? Btw., how does delegate_target_pos relate
> to instance_pos and when are we supposed to use has_target = false?
delegate_target_pos, instance_pos and array_length_pos (and maybe
others I don't know) are reals that specify where the implicit
argument goes (actual args are given integer values, and implicit args
are given the value of the actual arg + 0.1) e.g.
class MyClass {
  public void my_method (int[] ints);
}
we have actual arg ints (1)
and implicit args self (0) and ints_length1 (1+0.1)

so we end up with (self, ints, ints_length1) for the C args
if for example we set the array_length_pos to 0.9
we'll get (self, ints_length1, ints)
(the same goes for delegate targets)

the has_target=false for delegates means that the delegate doesn't
take a user_data argument (it was called static delegate in old vala
versions.

As for MarkupParser, I don't see a way to fix it apart from marking
the delegates as has_target=false and passing the user_data manually
(in fact actually writing C code but compiling with valac since you
won't be able to use instance methods).

Really, a struct that contains callbacks and not user_data's is not
Vala-ish at all (anonymous callbacks aren't really a problem unless
someone is doing something involving casts or variables).

I think it's better to write a small wrapper (e.g. a new constructor
accepting callbacks directly) or a patch to glib (I don't know if they
would accept it).

HTH,
Abderrahim