Re: [Vala] Patch: libgee:get_weak_ref

[Jürg Billeter <j bitron ch>]

On Fri, 2008-11-21 at 16:28 -0500, Yu Feng wrote:
> On Fri, 2008-11-21 at 21:03 +0100, Jürg Billeter wrote:
> > I understand your issue but I don't think that we should change the
> > return value of `get' to weak as this would make it impossible to
> > generate values in an iterator, for example.
> I don't understand. Can you give an example? I am not using a local copy
> with weak get. and everything works perfectly.

One example where this breaks is if you have an object that is
concurrently being accessed by multiple threads. To write a thread-safe
getter, you have to call, e.g., g_object_ref while holding the lock,
which is only possible if the g_object_ref is inside the getter. This is
not possible on the caller side.

> > An alternative is to default property getters to non-weak, this would
> > also solve similar issues in other situations. Any objections?
>
> Strong objections come from me. 
>
> The return values of properties shouldn't be strong by default.
>
> 0. weak or not in the property declarition describes the behavior of the
> property instead of the behavior of the getter and setters. A weak
> property holds a weak reference to the object; a strong property holds a
> strong reference to the object. No implications on the return values of
> the getters.

We could add support for a syntax like the following:

        public string foo { unowned get; set; }

That way we could properly separate reference/ownership handling of the
field and the getter.

> 1. Current way keeps the consistency between getter setter properties
> and member variable properties. Think about you have 
>    class A {
>       public Object foo;
>    }
>       A a = new A();
> I am free to create weak reference to A.foo by
>    weak Object ref = a.foo;
> and also strong reference to A.foo by
>    Object ref = a.foo;
>
> If I later on add setter and getters for foo, both code still work. New
> way will fail the weak one.

If you depend on that, you would have to explicitly specify it when
declaring the property. Please note that I don't want people to prevent
from using weak/unowned return values for getters, I'm just thinking of
changing the default to prevent hard to find errors due to memory freed
too early. If you know what you're doing, you will always be able to
explicitly specify the desired behavior.

> 2. Think about gluing the vala library with other c programs. Most GTK
> property getters return a weak reference; although the property itself
> holds a reference.

Yes, if you're writing a library in Vala and you want an ABI that
follows the GTK+ conventions as closely as possible, you'll have to add
weak/unowned modifiers at some places. However, that's already the case
now as method return values default to strong references while in GTK+
this is usually only the case where really necessary.

An additional advantage of changing the default would be that the ABI of
the library can remain stable for more implementation changes - if the
property value needs to be generated on the fly instead of returning a
stored value.

Jürg