On Sat, 2008-12-20 at 23:57 +0100, Hans Vercammen wrote: > 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. >
Thanks. I get the point from you and jurg's argument. Yu > > 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 > > _______________________________________________ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
