[Vala] Owned, unowned and weak references (Was: [BUG] Re: Closures and local variables)

[Sylvain Leroux <sylvain chicoree fr>]

On Wed, 2011-02-09 at 18:08 +0100, Jan Hudec wrote:
> owned means the code hold a counted reference. unowned means it does not. For
> reference-counted objects it's mostly cheap, but some objects don't have
> reference-count and for such objects assigning them to owned variable means
> copying them.
Thanks a lot for these clarifications Jan!
(and sorry for the late answer)

To summarize:
- owned = reference counted /or/ copied
- unowned = passed by reference (no copy, no ref count update)

By re-reading "Vala's Memory Management Explained"[0] at the light of
your explanations, things are now much more clear.

But, I noticed there's /weak/ references too. So what is the difference
between unowned and weak? Both leads to using an object by reference not
involving the reference counter.


> Callbacks in GLib representation are composed of the function pointer,
> pointer to data of unspecified type and in some cases (which correspond to
> owned delegates in vala) pointer to release function for the data.
>
> This leaves no way to reference the delegate. So it should only be possible
> to assign to unowned variable or transfer ownership (the (owned) cast) from
> one owned variable to another.
This leads to an interesting point of the design of Vala. If I
understand it well, the counter used for reference counting is usually
part of the referenced object. If the corresponding underlying "C
structure" does not have provision for such a counter, or, maybe, if the
reference is not directly accessible (like if it's "lost" when called as
a callback by a library function), reference counting is /not/ possible.
In that case, the only available options are those which do not involve
ref/unref operations. Namely "ownership transfer" or using "unowned
references". Or am I totally wrong?


As an alternative, instead of using reference counter stored as part of
the referenced object, one could store the latter in a hashmap.
"Locating" the reference counter for an object is then only a matter of
look-up in the map based on the address of the object. This is of course
not as fast as directly pointing to the counter, but it should be
reasonably efficient. And that solve the problem of obtaining the
reference counter of an object based only on its address (like in the
case of callback parameters). I think I've already saw such
implementation in frameworks using reference counters (maybe on NextStep
or Cocoa). Is there a reason for such option being rejected by the Vala
team?


> I believe Dova profile has different representation that does not have this
> limitation, but at the cost of interoperability problems.
Does this imply that the same Vala code could be semantically valid or
not, depending of the profile?


Best regards,
- Sylvain

[0] http://live.gnome.org/Vala/ReferenceHandling


-- 
Sylvain Leroux <sylvain chicoree fr>
http://www.chicoree.fr