On 07/01/2014 06:46, Tal Hadad wrote:
This case trigger me a question I wanted to ask before.
Why transforming ownership is nulling the original variable?
Instead of nulling, maybe just change variable to behave as unowned.
You might say that there is a problem in my solution, like this code:
uint8[] ar = new uint8[10];
if (some_method() != NULL)
another_method((owned)ar);
...
Since after the "if" case, valac can't determinate if ownership was given(at
compile time).
Despite of this, nulling "ar" variable is even worse in my opinion and it's
error prone.
The user might use "ar" varible later and it will crush he's application.
If he was lucky enough, he would realize that ar is null.
It's not easy to find that this line causing it.
I suggest solution for the last problem from valac side - treat ar as unowned
after the
(owned) operator, even if this operator was in "if" block!
That way, "ar" won't be null, and the user could use it later only as unowned.
And for class/struct fields - I do accept that they must be nulled when
transferring ownership.
What about:
if (foo) {
bar = (owned) ar;
}
// what now
This behavior is confusing.
_______________________________________________
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
