Re: [Vala] Ownership syntax changes

[Hans Vercammen <hveso3 gmail com>]

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:
> > >       * `(owned)' cast replaces `#' reference transfer expression
> > >
> > > Even less used, equally unintuitive. Example of new syntax:
> > >
> > > string foo = (owned) bar;
> >
> > I don't have a strong opinion on this since I don't really need it, but
> > using a cast expression feels a bit wrong. Not sure if we want to keep
> > the option open of having operator overloading, but what about something
> > like:
> >
> > string foo <= bar;
> > or
> > string foo << bar;
>
> In my opinion, this is not a lot clearer than the # syntax. The idea is
> to use a more descriptive syntax so that reading code gets easier. As it
> shouldn't be used often, a few characters more to type should not be an
> issue.

Yes, a descriptive syntax is very nice. However, I heard some good
arguments to include the flow of data whenever possible. Anyway, in my
opinion we probably shouldn't promote the explicit ownership transfer as
a feature but rather as a necessity to get some things done. So, an odd
syntax doesn't matter that much in this case.

> Furthermore, please note that it needs to be an expression, it can also
> be used as a method argument, not just in assignments.
>
> some_method (42, (owned) bar); 
>
> > >       * `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.
As a side note, we probably need to invent a similar functionality for
non-GObject classes *if* we want to avoid dangling pointers all
together. Also, I'm not sure how to treat the low level vala pointers in
this case.
Perhaps we can combine this with a compile option that is set by default
to enable runtime checks.

Hans