Re: [Vala] Various tests with the new contract support, but also with non-GLib.Object classes

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2008-04-24 at 08:54 +0200, Jürg Billeter wrote:
> On Thu, 2008-04-24 at 01:31 +0200, Philip Van Hoof wrote:
> > I also wonder where the memory for " t = test_new ();" is protected for
> > the use in app_thread_func as "app_y". As far as I can see is "app_test"
> > assigning app_y to t (and if app_y was not NULL, freeing app_y first).
> >
> > That's probably as a result of y = #t; where I demand an ownership
> > transfer.
>
> Yes, this statement transfers the ownership of the object references by
> `t' completely to `App.y', i.e. it also sets `t' to `null'.

Aha, if it sets t to NULL then ...

> > But the last line of app_test is going to free my t, right? Leaving me
> > with a broken app_y, which I will be using in app_thread_func later.
>
> The last line won't free `t', as `t' is now `null'. The issue here is

... indeed

> that `App.y' won't ever get freed as it's a static field, which is kind
> of problematic.

Yes

> For applications we could just free objects assigned to
> static fields at the end of main but that won't work for libraries just
> like that.

No indeed

> > Will this only ever work with GLib.Object inherited types (ones that
> > have reference counting)?
> >
> > Why not replacing "test_free" with a "test_unref" and adding a member
> > called ref_count to "struct _Test" and do it right in stead? When I make
> > myself a class in vala, I kinda 'okay' valac to do such things for me.
>
> Yes, we're planning to change this a bit. Classes that don't specify a
> base class will be reference-counted GType foundation classes, i.e. they
> will derive from GTypeInstance. Non-GType registered classes (without
> reference counting) will still be possible but will require an
> attribute.

Makes sense, indeed


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be