The bug is like this:
Look on my code:
[Compact]
public class DsRoot {
....
private void initialize_unit (DsUnit unit) {// line 137
// "managers" is a field (GLib.SList).
managers.foreach ((manager) => {
unit.foreach_object ((object) => {
manager.initialize_object (object);
});
});
}
// line 144
....
}
This code perform nested "foreach" action.
It looks fine on first look, but Vala compiler run into error:
graphics/drawing/nodes/ds_root.vala:137.59-144.9: error: duplicating DsRoot
instance, use unowned variable or explicitly invoke copy method
At first, I didn't understand the error, so I started testing with (/* */).
I've discovered that if I remove the second foreach like that:
[Compact]
public class DsRoot {
....
private void initialize_unit (DsUnit unit) {// line 137
// "managers" is a field (GLib.SList).
managers.foreach ((manager) => {
/*unit.foreach_object ((object) => {
manager.initialize_object (object);
});*/
});
}
// line 144
....
}
The error is gone.
The reason for this happan only in the second foreach, is that it requires user
data("manager" variable), while the first one doesn't.
So when Vala create the user data, it threat "self"/"this" as owned, while it
should be unowned, since the delegate parameter is unowned too.
I think Vala always threat this as owned since Vala used to deal with
GObjects(or ref-counted-classes), and always ref&unref them.
So I suggest that for fixing this bug, Vala should threat "self" as unowned for
targets of unowned delegates, no matter if they are ref-counted-classes nor
Compact.
What do you think? Am I right with my assumption?
Tal
_______________________________________________
vala-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/vala-list