Re: [Vala] Owned, unowned and weak references (Was: [BUG] Re: Closures and local variables)

[Sylvain Leroux <sylvain chicoree fr>]

On Tue, 2011-02-15 at 15:03 +0100, Xavier Bestel wrote:
> On Tue, 2011-02-15 at 14:51 +0100, Sylvain Leroux wrote:
> > As an alternative, instead of using reference counter stored as part of
> > the referenced object, one could store the latter in a hashmap.
> > [...]
> > Is there a reason for such option being rejected by the Vala
> > team?
>
> I guess the fact that Vala is initially GObject-based, which already has
> references in-object, is a good one ?
>
>       Xav

Of course it is ;) How silly am I...

But as you said, "Vala is /initially/ GObject-based". I'm still
discovering the language. But I think it would be unnecessary
restrictive to limit it to the GObject world. I assume this is why the
Dova project has started.

Nevertheless, even on GLib-based world there are some cases (like
delegates) where the current implementation leads to problems:

On Wed, 2011-02-09 at 18:08 +0100, Jan Hudec wrote:
> Callbacks in GLib representation are composed of the function pointer,
> pointer to data of unspecified type and in some cases (which
> correspond to
> owned delegates in vala) pointer to release function for the data.
>
> This leaves no way to reference the delegate. So it should only be
> possible
> to assign to unowned variable or transfer ownership (the (owned) cast)
> from
> one owned variable to another.

Moreover, I think this has implications for application-level objects
("compact" classes, classes not descending from GObject). To my mind,
Vala deterministic memory management is a real benefit. But, if, in
order to fully benefit of it, this require a strong coupling to GObject,
it is not that appealing.
So, maybe, an option to have a build-in alternate reference counting
scheme for non-GLib objects could be interesting.

As a matter of fact, I think such option might be implemented through a
clever use of mixins and CCode ref_/unref_functions. But that would be
much more elegant to directly support it at the language level.
 

- Sylvain

-- 
Sylvain Leroux <sylvain chicoree fr>
http://www.chicoree.fr