Re: [Vala] Patch: libgee:get_weak_ref

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 by
   weak Object ref =;
and also strong reference to by
   Object ref =;

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]