Hello,
I'll comment 'Balot 1' issues using qvto-dev-list since I'm not registered at OMG site.
I understand that issue QVT13-28 was inspired by [Bug 432112] "Inconsistency between scoped/unscoped result identifiers". However after some studies I see some inconvenience with the proposed solution.
Consider the following snippet:
mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {
}
helper h1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {
// return Tuple { ... };
}
helper h2(t : Tuple(r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass)) {
// ...
}
First case.
Suppose we need to initialize the former 'result' variable in m1() with the return value of h1(). With the accepted 'QVT13-28' (i.e. in case there's no 'result' variable) one have to do the following:
mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {
init {
var t := h1();
r1 := t.r1;
r2 := t.r2;
r3 := t.r3;
}
}
However having 'result' in place the snippet above will look like:
mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {
init {
result := h1();
}
}
Second case.
Suppose we need to pass the former 'result' variable to h2() somewhere in m1() population section. With the accepted 'QVT13-28' (i.e. in case there's no 'result' variable) one have to do the following:
mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {
h2(Tuple { r1 = r1, r2 = r2, r3 = r3 });
}
However having 'result' in place the snippet above will look like:
mapping m1() : r1 : OrderedSet(EPackage), r2 : EPackage, r3 : EClass {
h2(result);
}
Overall conclusion.
I have the feeling that this issue was raised as a way to solve some implementation flaws in QVTO. I mean that there's no theoretical problems and only implementation difficulties are solved by the issue.
To me the proposed modification impose more inconveniences than it tries to solve. And implementation flaws can be solved without intervention to specification.
Regards,
Sergey