Re: [Vala] reference management.

["Alexandre Moreira" <alexandream gmail com>]

On 3/20/07, Mathias Hasselmann <mathias hasselmann gmx de> wrote:
> Am Montag, den 19.03.2007, 17:18 -0300 schrieb Alexandre Moreira:
> > How exactly does reference management (g_object_ref || g_object_unref)
> > works in Vala ? I know it will unref everything I don't explicitly
> > tell it to ignore when returning methods (By the way, how do I tell it
> > to ignore anything ? I couldn't figure out the syntax)
>
> Hi Alexandre,
>
> Short answer:
>
> Reference counting happens automatically with vala.
>
> Long answer (also will put this on live.gnome):
>
> There are two kinds of references in vala: strong and weak references.
> For strong references g_object_ref and -unref are invoked, if no other
> functions are specified by CCode attributes. For weak references just
> pointer assignment happens. Some special-casing is used for GList, so
> you have to be carefully, which of your GList references are strong,
> and which of them are weak, as otherwise you might frequently clone
> your entire list by accident.
>
> Currently all member variables are strongly referenced by default. To
> make them weak add exactly this keyword. For local variables currently
> some heuristics exist. Weak still is preferred, but there are some
> thoughts to use always use strong references for local variables.
> Problem with strong references on local variables: Whilst strong
> references are quite cheap to maintain for GObject derived classes,
> they can be extremely expensive for things like boxed types or GList.
>
> Arguments for using strong references every where look like this:
>
>         Foo x;
>
>         if (bar) {
>                 Foo y = new Foo ();
>                 x = y;
>         }
>
> Citing Jürg:
>
>         Currently the compiler will define x as weak and y as strong
>         reference at the end of the if block, y will be unrefed and x
>         will have an invalid reference the only safe choice is to always
>         use strong references.
>
> While this problem still could be solved, by injecting some strong
> shadow ref at the scope of x, things become more tricky for things like
> this (also citing Jürg):
>
>         Foo y = bar.x;  // x is e.g. field with strong reference
>         bar.x = "foo";  // that will destroy the old value of bar.x
>
> or:
>
>         class Foo {
>                 public weak string foo_method() {
>                         return x;
>                 }
>
>                 public string x; // strong reference field
>         }
>
>         Foo bar = new Foo();
>         string x = bar.foo_method();
>         bar.x = "bar";
>
> At least the second case has no chance to be caught by the compiler and
> is one of the reasons mark-and-sweep garbage collection can be much
> faster then explicit memory management. On the other hand I wonder, if
> the class Foo isn't fundamentally broken, by returning weak references
> to non (semi) constant members.
>
> This this is a good time to discuss reference counting in Vala.

I don't know what exactly are the intents of the Vala project, and
that means I can't be sure on what is "best for Vala".

But "Vala as it is now" is mostly useful to people who can understand
GObject code and do the work of reference handling for themselves
(otherwise, they would have a hard time to figure out syntax and find
some errors)

I think it would be just great to allow the user to specify an "expert
mode" and allow him to do the ref unref by himself (just like GObject
does, giving G.Object a method to do each action) and, at most, having
the auto-unref-local-variables-unless-specified-otherwise.

Basically it would mean the addition of the ref/unref methods and an
option to set all references to weak.

I know *I* (and I know it doesn't mean much) would prefer working like
this. The more automatic behavior the more unpredictible or complex
are the rules to define "how each case is handled" and I believe these
unpredictible or complex rules create more of a mental effort to the
programmer than the activity of handling its own references.

Regards,
Alexandre Moreira.

PS: Please excuse any ortography errors on the above message. I am no
native english speaker and this machine doesn't have my spell checker
available.


> Ciao,
> Mathias