Re: [Vala] Confused with constructors

[Feng Yu <rainwoodman gmail com>]

On Sun, Feb 22, 2009 at 2:02 PM, Sam Danielson <samdanielson gmail com> wrote:
> The following code causes c compilation to fail.
>
> public class Baz : Object {
>
>        public string baz_string { get; construct; }
>
>        public Baz (string arg) {
>                if (arg.length > 2) this.baz_string = arg;
>                else this.baz_string = "done";
>        }
> }
>
> COMPILE:
> construct.c: In function 'baz_construct':
> construct.c:34: error: '__params_it' undeclared (first use in this function)
>
>
> It appears that the constructoresque Baz () may be limited to setting
> properties only in the form (this.baz_string = arg). Next question...
>
> public class Bar : Object {
>        public string bar_string { get; construct; default = "not set";}
>        public int bar_int = 42;
>
>        public Bar () {
>                message ("In Bar ()");
>                bar_int = 12;
>                bar_string = "hello";
>        }
>        construct {
>                message ("In Bar's constructor with bar_string = %s and bar_int =
> %d.", this.bar_string, this.bar_int);
>        }
> }
> public void main () {
>        var obj = new Bar ();
> }
>
> OUTPUT:
> ** Message: construct.vala:32: In Bar's constructor with bar_string =
> hello and bar_int = 42.
> ** Message: construct.vala:27: In Bar ()
>
>
> Additional lines in Bar () are executed AFTER the property is set to
> "hello" and after the construct {} block is called, even though
> this.bar_string = "hello" is the last line in Bar (). How does vala
> choose which code in bar to execute first? Should vala be made to
> abort with an error if it sees something besides setting a property
> in the constructoresque property setting method?
It used to abort with an error in 0.4.x or earlier versions.

The old behavior was to filter the property assignments, if the
construct properties were passed by g_object_new and the ordinary
properties were assigned after g_object_new.

The new behavior is to compile the entire CreationMethod -- especially
after the improvement on GTypeInstance based classes. Apparently the
old behavior(which should be fully preserved for GObject based
classes) was only partially preserved.

That explains why you were getting the bazzar errors: the property
assignments were inside an if block, and valac was confused -- the new
behavior and old behavior don't work well together.

> If Bar () sets member variables instead of properties the members will
> be initialized after the construct {} block is called. bar_int retains
> the value 42 until after the construct block is called.
>
> Perhaps my confusion stems from a general lack of understanding
> concerning properties and GObject. When would I use a property
> vs. just a regular instance variable and what is a managed property? I
> have used the C api to Gtk and dug into the glib/gobject source but I
> never really grasped the reason properties exist.

I guess one of the rules of the thumb is to always use getter/setters.
GTK is already sealing all the public member variables anyways.

The inability to
> compile certain things in the constructoresque property setter plus
> its control flow complexity has me scratching my head.
Try some different approach. Why is a control flow needed? is it
possible to eliminate the control flow from the CreationMethod?

The Vala
> tutorial and faq are correct in their treatment of these issues but
> they are also
> very minimal.
>
> Another odd thing:
>
> public class Foo : Object {
>        public int foo_int = 42;
>        public Foo foo_foo { get; construct; }
>
>        public Foo () {
>                foo_foo = this;
>        }
>        construct {
>                message ("%d", foo_foo.foo_int);
>        }
> }
> public void main () {
>        var obj = new Foo ();
> }
>
> The above code segfaults. foo_foo is a property so it should be set in
> Foo before construct {} is called but apparently it isn't because the
> fault occurs in foo_constructor(). Is this a bug? Can properties have
> an Object type?

This behavior should be related to Bug 572079.

> Also, is it (or will it be) possible to overload the constructoresque
> property setter on type and arity? I currently get an "already
> defined" error.

Never tried to do so.
> Finally, what is the constructoresque property setter actually called,
> or is "Constructoresque property setter" a good name?
No idea. Isn't it just a regular setter? 'construct' stands for a
special Flag when calling g_object_install_property.

> -Sam Danielson
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list