| [qvto-dev] Issue 13268: Ordered Tuples |
|
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. |