[
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