Re: [Vala] Ownership syntax changes

[Hans Vercammen <hveso3 gmail com>]

On Sun, 2008-12-21 at 00:16 +0100, Jürg Billeter wrote:
> On Sat, 2008-12-20 at 23:57 +0100, Hans Vercammen wrote:
> > On Sat, 2008-12-20 at 08:24 +0100, Jürg Billeter wrote:
> > > On Sat, 2008-12-20 at 02:19 +0100, Hans Vercammen wrote:
> > > > On Fri, 2008-12-19 at 12:10 +0100, Jürg Billeter wrote:
> > > > >       * `unowned' type modifier complements `weak' type modifier
> > > > >
> > > > > `weak' only make sense for reference fields, list elements, and local
> > > > > variables to break reference cycles. Vala will use
> > > > > `g_object_add_weak_pointer' in these places in future versions.
> > > >
> > > > I definitely agree we should avoid dangling pointers as much as
> > > > possible. However, I fear a bit that many people will turn to using
> > > > pointers when this is also applied to local variables.
> > >
> > > Why do you think people will switch to pointers? Do you have an example
> > > in mind where the change might cause issues?
> >
> > I don't see an immediate use case where this might fail. However, weak
> > local variables can be used to tweak unnecessary reference counting
> > overhead. Registering the pointers possibly invalidates this tweak. We
> > have to wait an see how this actually behaves in for example loops etc.
> > Judging from the implementation within GObject, weak references might
> > actually be slower as strong ones.
>
> You should not use weak for performance improvements with the new
> syntax, it's only meant to break reference cycles or to not keep an
> object alive for other reasons.
>
> The unowned modifier will still allow you to avoid any kind reference
> counting or tracking. There will just be no guarantees at all if you do
> that.

Ok, clear. I wasn't sure "weak" and "unowned" would be treated
differently.

> > together. Also, I'm not sure how to treat the low level vala pointers in
> > this case.
>
> If you use raw pointers, you are on your own, I don't think it makes any
> sense to try to make the code safer there. Better try to avoid
> situations where raw pointers are necessary.

Exactly.

Hans