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.
|