Re: [Vala] Ownership syntax changes

[Hans Vercammen <hveso3 gmail com>]

On Sun, 2008-12-21 at 13:25 -0500, Yu Feng wrote:
> 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.
>
> I am confused with weak and unowned. Saying if gtk_window_list_toplevels
> returns a list of GtkWindows, should these be unowned or weak?
>
> List<weak Widget> Gtk.Window.list_toplevels();
> or
> List<unowned Widget> Gtk.Widget.list_toplevels();
>
> Because in devhelp it is written that the elements are not referenced:
>         
>         Returns a list of all existing toplevel windows. The widgets in
>         the list are not individually referenced. If you want to iterate
>         through the list and perform actions involving callbacks that
>         might destroy the widgets, you must call g_list_foreach (result,
>         (GFunc)g_object_ref, NULL) first, and then unref all the widgets
>         afterwards.

Using GLib.List<unowned Widget> would be more appropriate in this case.
If I understand correctly, using "weak" for list elements would allow
you to have a collection of "unowned" references that are also tracked
on validity. (for the types that support it) The keyword "weak" would
change to an abstract data type instead of a simple type modifier.
        
>         
> perhaps weak will be useful only for member variables(they are on the
> heap) after the invention of 'unowned', given the add_weak_pointer use
> case?

I don't think it's feasible to track the weak references throughout the
stack. However, using local weak tracking references probably have there
uses in a single threaded environment where you don't necessarily need
to keep the object alive. In general you would not need weak or unowned
member variables if it wasn't for the cyclic references. Preventing
these side-effects in a good shared/ownership design probably saves you
a lot of hunting time afterwards in my opinion.

Hans