Conflicting exclusion of null during assign
"A compound assignment is equivalent to perform as much simple assignments as there are expressions. Null values are skipped."
This is poor English and it conflicts with the OCL specification.
Pedantically it only skips "Null" values so "null values" are allowed anyway.
"An assignment may receive a future variable produced by a deferred resolve expression (see ResolveExp). The effect is equivalent to receive a null value except that a side-effect action occurs in order to allow re-executing the assignment at the end of the transformation.
An assignment expression returns the assigned value unless it is a future value, in which case null is returned."
This is barely intelligible and presumably related to the SmartQVT implementation. It certainly has confusion about nulls.
I recommend following OCL and allowing null values. ->excluding(null) is easily added.
Issue 19238
AssignExp to an Collection should make clear that the results is
target->including(source)->excluding(null)
Issue 19687
The two examples
mymultivaluedproperty += object Node
{
}; // additive semantics
mymultivaluedproperty := object Node {
}
; // the list is reset and re-assigned
are simple assignments from single valued RHS. These are not covered in the preceding description.
I consider both to be errors since the RHS is unsuitable for assignment to the LHS. In both cases an asSet() or whatever should be appended.
More generally, the library operation that exhibits the "additive semantics" should be clearly identified.
Since addition to OCL collections is not permissible, it may be necessary to define constructors, so that
var c : Set(String) := Set
{"a"}
;
invokes the Set(T)(Set(T)) constructor.
This would allow initialization for a Sequence from a List and vice-versa that is otherwise magic.
which should exploit an OCL definition of OrderedSet::including to be add at end if necessary.
Discussion - nulls
UML does not allow nulls in multi-values, therefore nulls must be excluded during assignments to properties.
OCL does allow nulls, and even though this may appear to be a mistake, QVTo must support nulls in OCL collections until OCL is changed.
Discussion - multiple values
The current wording leaves open the design choice between:
a) perfect fidelity of nested types, i.e. addition of a Collection of Collections adds the one Collection of Collection element
b) perfect flattening, i.e. addition of a Collection of Collections adds all the elements in the nested collections.
c) something in between, perhaps behaving differently depending whether the LHS is a nested collection or not,
OCL unfortunately started without nested collections so that imploicit-collect flattens requiring the explicit collectNested for perfect Collection type fidelity. a) is not really an option. c) risks a confusing anarchy. b) is what is often wanted. If users want nested collections they can use more explicit operations.
Discussion - future values
Premature access to yet-to-be initialized values is obviously bad. Making this an error is an option, but it would be a breaking change; there may be users who poll the variable awaiting initialization. Simplest to just clarify the words to indicate that the value of any yet-to-be-initialized value is null, even when null is not assignable to the value. It is not initialized to null; it is null until initialized.