Hi
Thanks. You were one of the most likely users to come up with a
must-have use case.
Yes, we are well aware that Eclipse QVTo is deficient for
OrderedTuples. But just because an implementation is bad doesn't
necessarily mean the specification is bad.
Regards
Ed Willink
On 06/01/2014 17:58, Rouquette, Nicolas
F (313D) wrote:
Ed,
OrderedTupleType seems misguided to me as well.
I checked the Eclipse QVTO implementation, which we use
extensively at JPL.
There is no unit test based on the syntax of
OrderedTupleTypes.
In practice, I believe that Eclipse QVTO supports only
TupleType, not OrderedTupleType.
Unlike the QVT 1.1 spec, Eclipse QVTO packs return parameters
in a TupleType, not an OrderedTupleType.
transformation TupleTests();
intermediate
class A {
id : String };
constructor A::A(_id : String) {
result.id := _id; }
main() {
var i1 : A =
new A('i');
var i2 : A =
new A('j');
//var
t1 :=
Tuple{i1,i2}; //
error: "="
expected instead
of ","
//var
x1 :=
t1.at(1);
//var
y1 :=
t1.at(2);
var t2 :=
Tuple{x=i1,y=i2};
var x2 := t2.x;
var y2 := t2.y;
var r :
Tuple(x:A, y:A) =
map foo('test');
var rx := r.x;
var ry := r.y;
assert
fatal (rx.id='testx');
assert
fatal (ry.id='testy');
}
mapping
foo(in prefix:String) : x:A, y:A {
init {
x :=
new A(prefix+'x');
y :=
new A(prefix+'y');
}
}
Hi
Please read at least as far as the
------------------------------------- separator.
Apologies for this long email. I'm attempting to summarize
some of the discussion on the Eclipse qvto-dev newsgroup
and my more detailed analysis of the specification.
The status of many things related to OrderedTuple in the
QVTo specification is poor.
We have a choice:
a) Endorse OrderedTuple, fix the problems and look to
promoting OrderedTuple to OCL.
b) Treat OrderedTuple as misguided and look to deprecate
it.
My preference is to deprecate OrderedTuple/UnpackExp and
write a longer Issue 13268 resolution accordingly.
However if a strong case can be made for OrderedTuple,
then an even longer 13268 resolution must fix the
problems.
Either way Issue 13268 is withdrawn from Ballot 1. You can
skip the following analysis if you share my deprecation
preference.
Regards
Ed Willink
----------------------------------------------------------------------------
The Pack/Unpack use case
var a:A := ...
var b:B := ...
var t := Tuple{a, b}; // OrderedTupleLiteralExp
...
var (a1,b1) := t; // UnpackExp
An OrderedTupleLiteralExp followed by an UnpackExp allows
miscellaneous information to be packed and unpacked
without naming each element.
This may sometimes give a lexical access saving in
constrast to using OCL Tuples:
var t := Tuple{a:A = ..., b:B = ...}; //
TupleLiteralExp
...
-- var a1 := t.a;
-- var b2 := t.b;
As the example shows, the overall saving is not
necessarily large or even positive. OrderedTuples
introduce a hazard from mis-aligned positional parts.
However, this functionality is sufficiently clearly
specified that outright removal would be a breaking
change.
Recommendation: deprecate OrderedTupleLiteralExp/UnpackExp
etc as unnecessary bloat.
The OrderedTuple::at() use case
8.2.2.7: Tuple elements can be accessed individually
using the at pre-defined operation.
Oops. The OrderedTuple::at() operation is not specified
anywhere else.
In particular, if at() was specified, its return type
would be data dependent demonstrating the worst
characteristics of reflection.
In contrast, access to a Tuple part has a well-defined
type and, if a reflective Tuple access was provided, there
is a possibility that it could be type safe.
Recommendation: Eliminate the suggestion that an at
operation might exist.
The Helper/Mapping return use case
This issue started because of the bad wording for helper
returns. If we try to construct a complete example we
highlight new problems.
The major example is in 8.1.2
mapping Foo::foo2atombar () : atom:Atom, bar:Bar
merges foo2barPersistence, foo2atomFactory
{
object atom:{name := "A_"+self.name.upper();}
object bar:{ name := "B_"+self.name.lower();}
}
This uses named returns and consequently an OCL Tuple
return and so poses no real confusion (but see Merge
footnote)
Continuing we find
var (atom: Atom, bar: Bar) := f.foo2atombar();
which unpacks an OCL Tuple return. This is not supported
by an UnpackExp that requires an OrderedTuple. Surely it
should be
var t := f.foo2atombar();
-- var atom := t.atom;
-- var bar := t.bar;
There does not appear to be a full example of an
OrderedTuple return. Reworking the example to use one, we
could elimninate the return names giving
mapping Foo::foo2atombar () : Atom, Bar
merges foo2barPersistence, foo2atomFactory
{
Tuple{
object atom:{name := "A_"+self.name.upper();},
object bar:{ name := "B_"+self.name.lower();}
}
}
and provide a specification that a list of unnamed return
types e.g. "Atom, Bar" is a shorthand for "Tuple(Atom,
Bar)"
A Mapping of this form cannot do piecemeal assignment to
the named result variables, so a great deal is lost and
very little gained.
Recommendation: implicit OrderedTuple return types have
dubious benefits and are barely motivated by the
specification so we can eliminate them
A return must either be an optionally named Type or an OCL
Tuple of named Types.
The asOrderedTuple Use Case
The Object::asOrderedTuple() : OrderedTuple(T) library
function provides a limited reflective capability with a
rather poor description.
Converts the object into an ordered tuple. If the
object is already an ordered type, no change is done.
What is an ordered type? Is a Sequence or List an ordered
type?
If the object is an OCL Tuple, the list of attributes
become the anonymous content of the ordered tuple.
Is this really intended? I would expect the values to
become the content. Either way this is a non-determinstic
conversion.
Otherwise, the operation creates a new tuple with a
unique element being the object.
I guess it means a single element OrderedTuple containing
the source, but for a class, I would really like to see
the properties/values.
The above functionlity would appear to be provided by
Tuple::keys() : Set(TypedElement) to get a set of the
Tuple name+type parts.
Tuple::at(TypedElement) : OclAny to get a selected part
value
and extended by
OclElement::asTuple() : Tuple to give a Tuple of
name+type+value parts.
Recommendation: deprecate asOrderedTuple in favour of
Tuple::keys/at in OCL.
Merge footnote
In 8.1.2 we find
We should note that conceptually a result parameter is
treated as an optional parameter of the mapping
operation. Thus,
the first call of “f.foo2atombar()” is equivalent
to invoke “f.foo2atombar(null,null).”
This seems to be absolute rubbish. But it might make some
kind of sense once someone specifies the subtleties of
merge semantics.
If merge is a lexical mash, then no passing is needed.
If merge is a disciplined call sequence, then good sharing
is needed.
Anyway that's a different issue.
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3658/6979 - Release Date:
01/06/14
|