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

Reply via email to