Re: [Vala] use weak and var together

[Hans Vercammen <hveso3 gmail com>]

On Sat, 2009-01-10 at 21:12 -0500, Yu Feng wrote:
> On Sat, 2009-01-10 at 23:48 +0100, Hans Vercammen wrote:
> > On Sat, 2009-01-10 at 13:07 -0500, Yu Feng wrote:
> > > On Sat, 2009-01-10 at 18:35 +0100, Jürg Billeter wrote:
> > > > On Sat, 2009-01-10 at 12:19 -0500, Yu Feng wrote:
> > > > > On Sat, 2009-01-10 at 09:24 +0100, Jürg Billeter wrote:
> > > > > > On Sat, 2009-01-10 at 01:04 -0500, Yu Feng wrote:
> > > > > > > On Fri, 2008-12-12 at 08:08 +0100, Jürg Billeter wrote:
> > > > > > > > On Thu, 2008-12-11 at 23:56 -0500, Yu Feng wrote:
> > > > > > > > > Talking about circular references, is it possible to have a
> > > > > > > circular ref
> > > > > > > > > breaker mechanism like the one in GTK for vala fundamental classes?
> >
> > I'm not very familiar with the inner workings. But don't they explicitly
> > destroy the objects instead of simply unreffing like vala does?
> Neither am I. GTKObject has a destroy signal to do the magic with
> g_ojbect_run_dispose. Cycle references are automatically resolved. the
> relavent code are in gtk/gtkobject.c but I didn't have time to study it
> carefully.

As far as I can tell they use the gtk_widget_destroy function. Which in
turn explicitly calls g_object_run_dispose.

> > > > > > > > I don't think we should always add a dispose mechanism to fundamental
> > > > > > > > classes. However, if someone wants to use that, it should still be
> > > > > > > > possible to implement this with a bit of extra Vala code.
> > > > > > >
> > > > > > > I suddenly realized it is impossible to write dispose mechanism with
> > > > > > > extra vala code because one can not override the hidden unref method,
> > > > > > > therefore one can not do the cycle detection/breaking at the right time.
> > > > > >
> > > > > > unref methods are never virtual in GObject. However, you can override
> > > > > > the dispose method in Vala. Is this what you meant or can you explain
> > > > > > what exactly you want to achieve?
> > > > >
> > > > > No. We were talking about GTypeInstance fundamental classes in that
> > > > > mail. They don't have a 'dispose' method to be overriden.
> > > >
> > > > Right, but I'm not sure that you need to change anything in the unref
> > > > function to get dispose functionality working. Can you explain more
> > > > specifically what you can't get working with the current possibilities?
> > >
> > > Yes I can do this:
> > >
> > > class Object {
> > >    Object ref_to_there;
> > >    Object ref_to_here;
> > >    private disposed = false;
> > >    public virtual void dispose() {
> > >          /*release references here*/
> > >       ref_to_there = null;
> > >       ref_to_here = null;
> > >    }
> > >    private void run_dispose() {
> > >       if(disposed) return;
> > >       disposed = true;
> > >       dispose();
> > >    }
> > >    public void destroy() {
> > >       Object holder = this; 
> > >       /*needed if invoked from a weak reference of this*/
> > >       run_dispose();
> > >       holder = null;
> > >    }
> > > }
> > >
> > > Then Object.destroy can be used to manifestly break any cycle
> > > references.
> >
> > Why do this manually? Don't you need to chain the dispose handlers
> > throughout the hierarchy to make it usable somehow?
> But this is not a GObject. It's about implementing two stage disposal
> and ref breaking with GTypeInstance classes.

Yes, I understand. But if you can't free/break the possible cyclic
references of the private members from the base class, there is
basically little use in providing a virtual/override system for a
dispose method (either GObject or non-GObject). So think providing a
class dispose method for the fundamental classes is a good idea :)
(considering member references would be freed in the dispose method in
both cases).

Hans