Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] Issue 13268: Ordered Tuples .was: QVT 1.2 RTF Ballot 1 preview 1 
Hi
You can only have a breaking change after something has been working. It seems UnpackExp is unseable in Eclipse QVTo, so it is only Smart QVT users who might see a change.
The signature/overloading of operations with named outs is totally undefined. To avoid contravariance problems perhaps outs are ignored and inouts must be exact.
Given the lack of UnpackExp functionality, eliminating OrderedTuple and UnpackExp has to be the simpler approach. 

But what do real QVTo users think?
Since we don't really care, I suspect that deferring the issue is best to a void a cannot-reballot a decided issue hazard. 

    Regards

        Ed

On 03/01/2014 18:42, Adolfo Sanchez-Barbudo Herrera wrote:

Hi Ed,
The proposed 3-protocol support doesn't seem appropriate because it produces more inconveniences than advantages (I see no advantages): it would imply that operation parameter names were part of the operation signature (API).
Eclipse QVTo advocates for a practical a)-c) solution, which is of course against the specification and can't provide support to "unpack" expressions.
IMO, your a), b), c) analysis could make sense provided a) returned an OrderedTuple. It could even be arguable, that b) is required, that is, giving support to unnamed out parameters when returning multiple results is questionable.
The practical Eclipse QVTo a), c) solution seems convenient but it's a breaking change not acceptable for QVT 1.2. Probably, not acceptable for a serious language evolution. Therefore, an a)-returning-OrderedTuples, c) solution seems the more sensible one to go for. 

TL;DR version below.

Regards,
Adolfo.

------- TL;DR --------

** Proposal rationale **
What's the benefit of having the proposed 3-protocol support, rather than the current 2 protocol one ? 
- multiple results returns an OrderedTuple type.
- single result returns the declared type.
In my opinion, it looks like a change to make the life harder without apparent benefit. The main issue is that now, out parameter names would be involved in the operation signature (i.e. API), which is not usual, hence an inconvenient:
- With multiple results, to check a valid operation call, we not only have to take into account about the out parameter types, but also their names (to know the named parts of the returned OCL Tuple, if it were the case).
- Note that unpack expressions, couldn't be used with OCL Tuples because their parts don't involve any order. This means that when using unpack expressions as the LHS of an assignment in which the RHS is an operation with multiple results, the usage would be valid/invalid depending on out parameter names are declared or they are not.
In essential, a valid operation call could not be valid any more, if we suddenly change out parameters names of the operation they are calling. This is not usual and provides inconveniences rather than advantages. Actually I see no advantages, since you can still declare your operations to return OCL Tuples as a particular case of c). 

**UML**
You know better than me what's going on with UML, but when UML operations declare "multiple" results, they are all from the same type, so Tuples should not be involved as a return type of an operation, shouldn't they? 

**Eclipse QVTo**
After a quick exercising, they basically support your a) and c) cases:
- UnpackExp not supported.
- Operation's multiple unnamed out parameters not supported (I've not found any example in the QVTo spec about this, though). 
- Multiple results operations, return OCL tuples.

** Conclusion **
IMO, your a), b), c) analysis could make sense provided a) returns an OrderedTuple.
The alternative of just supporting an a) - c) proposal and getting rid of the UnpackExp and OrderedTuples sounds too much hard breaking change. On the other hand, Eclipse QVTo would be happy with it, since it's taken approach. The problems above would vanish since there would not be UnpackExps and OrderedTuples, and we could consider a "multiple results" declaration, as a syntactic sugar of a single result OCL tuple declaration. Notation would be consistent since a piecemeal assignment is not more than assigning to the implicit result variable:
helper foo(): one: String, two:Integer { // result : Tuple(one: String, two : Integer) 
  one := "1" // result.one := "1"
  two := 2   // result.two := 2
}
Also note that, "one" and "two" can't never be omitted, since they were not out parameter variables, but the named part of an OCL tuple.
Simplicity is the only argument to defend this, but breaking changes are always a bad idea. Likewise, as additional issue, due to the fact that it's a syntactic sugar resolution, it might be confusing for the user that "one" are "two" are not really out parameters, but the named part of an OCL Tuple. In any case, this language design correction can't be done for QVT 1.2, but for a QVT 2.0 (even a breaking change at concrete syntax notation doesn't seem acceptable).
Since it's not clear that unnamed out parameters were intended in multiple results operations, a tractable solution for the QVT 1.2 specification would be the mix-in: 
a) returning OrderedTuples for multiple result operations.
c) returning the declaraed type for single result operations.

On 31/12/2013 17:47, Ed Willink wrote:

Hi Adolfo

[It seems to be rare that the section numbers/pages in an OMG Issue are
accurate by the time the issue is considered.]

After reviewing OrderedTuples, I find the specification very patchy. The
only benefit of an OrderedTuple seems to be to allow a dangerous
association by position, possibly checked by accidental type mismatch.
Association by name (and type) is much more reliable. Given a free
choice I would eliminate OrderedTuple completely. The interesting
Object::asOrderedTuple() could be moved much more consistently to
Classifier::asTuple().

I'm not clear how a helper can usefully return its tuple short of  a
'bulk' return Tuple{x,y,z}.

It seems a helper could be declared in three ways.

a) with multiple named result parameters. In this case the return can be
an OCL Tuple, populated piecemeal by assignments, or a bulk return

b) with multiple result parameters at least one of which is an unnamed.
In this case the return must be an OrderedTuple populated by bulk return

c) with a single result parameter which might be named. In this case the
return must be the type populated by direct return.

The current wording is vague enough to allow all the above.

Much as I dislike OrderedTuple, prohibiting b) would make UnpackExp
useless too, so b) must be an option.

Prohibiting a) is inconsistent with allowing named result parameters.
Piecemeal assignment is possible using 'out' parameters, so named result
parameters and synthesized Tuple returns could be redundant. But
overloading presumably forms a signature from the in/inout/out types
ignoring the result types so they are not redundant after all.

I suppose we have to do a significant clean up of the wording of Helper
and ReturnExp clearly distinguishing the three call protocols returning
Type, OrderedTuple, Tuple. Perhaps every reference to tuple needs review. 

What does Eclipse QVTo actually do?

     Regards

         Ed Willink

On 31/12/2013 15:06, Adolfo Sanchez-Barbudo Herrera wrote:

Hi

For allusions in the document. In issue 13268:

OCL Tuples contain named tuple parts. The operation's returned tuples
for multiple results can't deal with named tuple parts. Note that
having multiple results, is different to have a single result whose
type may be an OCL Tuple, which is of course accepted/valid.

Precisely, OrderedTuples (and other concepts like UnpackExp) are
required/introduced in QVTo to deal with operations with multiple
results.

I doubt that normal OCL tuples can similarly deal with this issue,
what respects to UML operations.

It could be arguable that the clarification of "ordered tuple" is
needed. Given the current resolution of this issue, the clarification
is clearly required.

Minor extra:
- The section number (from the issue title) has changed from 8.2.1.11
to 8.2.1.12 (in QVT 1.1)

Regards,
Adolfo.
--
On 31/12/2013 13:27, Ed Willink wrote:

Hi

The first preview of QVT 1.2 RTF Ballot 1 is attached.

Preview 1-Jan to 8-Jan
Voting 8-Jan to 22-Jan

The resolutions in this ballot are mostly the oldest (so mostly QVTc),
or most controversial. QVTo-only reviewers may prefer to look at the
No-Changes.

All working material may be found at
http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to
Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4 
server (1.7 seems fine).

Most of the resolutions for Ballot 2 and 3 can be found in
QVT1.2RTFBallotAll.odt.
I do not feel confident enough to address the following so they will be deferred unless someone comes up with the bulk of a resolution proposal. 
i.e. discussion and editorial changes.

http://www.omg.org/issues/qvt-rtf.open.html#Issue12370
http://www.omg.org/issues/qvt-rtf.open.html#Issue13082
http://www.omg.org/issues/qvt-rtf.open.html#Issue13103
http://www.omg.org/issues/qvt-rtf.open.html#Issue13168
http://www.omg.org/issues/qvt-rtf.open.html#Issue13180
http://www.omg.org/issues/qvt-rtf.open.html#Issue15376
http://www.omg.org/issues/qvt-rtf.open.html#Issue15390
http://www.omg.org/issues/qvt-rtf.open.html#Issue17538
http://www.omg.org/issues/qvt-rtf.open.html#Issue18323
http://www.omg.org/issues/qvt-rtf.open.html#Issue18324
http://www.omg.org/issues/qvt-rtf.open.html#Issue18325
http://www.omg.org/issues/qvt-rtf.open.html#Issue18363

     Regards

         Ed Willink

On 28/12/2013 13:17, Ed Willink wrote:
Please reply to this email to confirm that you are able to participate 
in the ballots (and identify any resolutions you feel able to write).

No replies. I hope you're all enjoying a long break.


_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev


_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3658/6963 - Release Date: 12/31/13 




_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev

_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3658/6973 - Release Date: 01/03/14

Back to the top