Re: [Vala] Gtk.RecentFilterInfo and some interface issues.

[Frederik <scumm_fredo gmx net>]

On 12/14/2010 07:27 PM, Erick Pérez Castellanos wrote:
> Hi:
>
> I have two issues right now coding in vala:
>
> First:
> I'm using Gtk.RecentFilterInfo, and i got this:
>
> Gtk.RecentFilterInfo a = new Gtk.RecentFilterInfo();
> error: 'Gtk.RecentFilterInfo' does not have a default constructor
>
> and my question is how to instantiate that. Now I've found that in Gtk
> c code GtkRecentFilterInfo is just a struct, and in gtk+-2.0.vapi is
> declared as a class (annotated with Compact modifier). Could this be a
> bug ?

Yes, it should be a struct, not a compact class.

> Second:
> In Gtk.RecentChooser interface there are properties: i.e.: limit not
> declared abstract, and I suppose i don't have to instantiate those in
> my class (which is implementing the interface), but when I'm using
> that property I'm getting warning from GLib that myClass doesn't have
> the property.

Then they should be abstract in the vapi and you have to provide them
in your class implementing the interface.

> Note: Vala compiles just fine, but when running is when I'm getting
> the error.
>
> It would be useful to update a little the examples from
> http://live.gnome.org/Vala/Documentation, or make the properties
> explanation more clear.
> Is it always needed to use backend attributes of the classes for every
> declared properties ?

No, a property value can be calculated from other values on access,
for example:

        public int foo {
                get { return 42 * some_method (); }
        }

> How I refer to the properties inside the class, with the property name
> or the backend attribute ?

Inside the class you can refer directly to the data field, if you know
that you don't depend on other code to be executed in the property
getter/setter.

        private int _foo;

        public int foo {
                get {
                        log ("Somebody is getting foo");
                        return _foo;
                }
                set {
                        _foo = value;
                        update_something ();
                }
        }

Whether you refer to '_foo' or to 'foo' depends on whether you want
'log ()' and 'update_something ()' to be called or not. If you do a
standard implementation it should make no difference:

        private int _foo;

        public int foo {
                get { return _foo; }
                set { _foo = value; }
        }

But be aware, that if you enhance the getter or setter later, you have
to revisit all your accesses to _foo and check if they represent still
what you mean.

The standard property implementation above can be written shorter:

        public int foo { get; set; }

But in this case you should better refer to 'foo', not to '_foo', even
though the compiler implicitly generates a private '_foo' data field.
I think the compiler should not allow access to '_foo', but currently
it does. So better don't depend on it.


Best regards,

Frederik