Community
Participate
Working Groups
Currently, the implicit population section in mappings can only consist of so called patternPropertyOrAddition elements, which are in fact assignment to properties. The explicit population section currently supports a list of oclExpressionCS, i.e. it enables all expressions from OCL and most of the imperative expressions from QVTO, except assignments, variable initializations, log and assert expressions. The end section enables all kinds of imperative expressions. That would be great if not the spec! It says we can have any kinds of expressions in the population section. It is allowed by the grammar: <population_section> ::= <expression_list> | 'population' <expression_block> <expression_list> ::= <expression_semi_list> ';'? <expression_semi_list> ::= <expression> (';' <expression>)* <expression_block> ::= '{' <expression_list>? '}' <expression> ::= <assign_exp> | <let_exp> <var_init_exp> and so forth to any other expressions. The spec also drops the following hint. In the simplest case of a single result the contents of an implicit population section are considered to be the contents of an implicit object expression. (8.2.1.19). Thus, all expressions allowed in ObjectExp body are allowed in the population section. The ObjectExp permits any expressions, including arbitrary assignments. This is proved in the examples in 8.2.1.18 and 8.1.5 and by the grammar rule: <object_exp> ::= 'object' ('(' <iter_declarator > ')')? <object_declarator> <expression_block> Judging by what is written above, I consider that any kinds of expressions should be allowed in implicit and explicit population sections.
Another technical question is name clashing. What if a local variable clashes with some property? There are three ways to deal with that: 1. Resolve the ambiguity to the property 2. Report an error 3. Resolve to the variable I think the first approach is definitely wrong. Consider a metamodel update which adds or removes some clashing property - the QVTO script might unexpectedly change its behaviour. The second variant is better. But in case of a metamodel update (adding some new property) some scripts that used to work correctly would not compile. I prefer the third variant. Metamodel updates would be transparent to legacy scripts. It is closer to Java where local variables in scope hide fields.
I'd also prefer variant 3) since it provides most robustness to external influence like metamodel changes.
(In reply to comment #1) variant 3 sound best to me too.
Fixed.
