Re: [Vala] GBinding support?
- From: Fredderic Unpenstein <magentus gmail com>
- To: Frederik <scumm_fredo gmx net>
- Cc: vala-list <vala-list gnome org>
- Subject: Re: [Vala] GBinding support?
- Date: Mon, 21 Jun 2010 17:29:28 +1000
On 21 June 2010 01:57, Frederik <scumm_fredo gmx net> wrote:
GLib/GObject 2.26 will add property binding [1]. The straightforward way to
support this in Vala would be:
Object.bind_property (foo, "x", bar, "y");
Object.bind_property (foo, "x", bar, "y", BindingFlags.BIDIRECTIONAL);
Would foo.x.bind_property be a possibility? And perhaps
bind_bidirectional or bind_with (do you bind anything else, other than
properties, on an object property?)... Maybe then also bind_property
could become bind_to or something equaly less redundant?
Also, is there any way to get rid of the need for BindingFlags in
that? If the argument IS a BindingFlags, Vala could include that
scope when looking up bare words...?
However, this is not very type-safe. Would direct language support be
reasonable? E.g. something like
foo.x +> bar.y; // default
foo.x <+> bar.y; // bidirectional
Or is it too cryptic?
There's also := type notation, which fels like "more than assignment".
Though since binding takes flags, I worry that it'll end up going the
same way as += for signal connection.
Personaly, I like the operators, but they're a little limited once you
add extra varients or options, as with the connect family. Unless
some syntax is added for general operator functions... eg:
foo.x +> [BIDIRECTIONAL] bar.y;
which could also make += signal connection useful again. Perhaps
adding support for a bracketed comma-separated list with the extra
arguments, instead.
And how to deal with 'g_object_bind_property_full'? It takes two TransformFuncs
but only one user_data/GDestroyNotify pair.
(foo.x, celsius_to_fahrenheit) <+> (bar.y, fahrenheit_to_celsius);
(foo.x, (b, s, t) => { }) <+> (bar.y, (b, s, t) => { });
That's sort of what I was saying with bracketing above, too. A
general syntax pattern like that might help with other places where
syntactic support would be useful but presently shunned.
Fredderic
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]