Re: [Vala] Ownership syntax changes

[Jürg Billeter <j bitron ch>]

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.

> As a side note, we probably need to invent a similar functionality for
> non-GObject classes *if* we want to avoid dangling pointers all

Yes, either that or we should probably at least warn when using weak for
types that do not support it.

> 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.

> Perhaps we can combine this with a compile option that is set by default
> to enable runtime checks.

I'm not sure whether that's such a good idea as semantics would change.
If you expect the reference to be null after the object has been
destroyed, the application wouldn't work anymore when disabling the
runtime check. After all, you can use `unowned' or raw pointers in
performance critical parts, if really necessary.

Jürg