Hi again
In general I like the approach of making all object creation visible to ‘resolve’. I consider this as a best practice, but also fairly optimistic to hardwire
into the specification.
The prohibition implies no ‘object’ instantiations and mapping calls inside a query/helper. However, the same applies to constructor invocations.
If we really want to restrict object creation to mappings, then a constructor/object instantiation for type A may be invoked only inside the init section of a
mapping with the same return type A, or some super type. In addition we must ensure that there is at most one runtime instantiation inside the init section, and that the instantiated object is eventually assigned to the ‘result’ variable.
There must be a really good control flow analyzer to ensure the above restrictions.
Kind regards
Christopher
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Ed Willink
Gesendet: Donnerstag, 8. Oktober 2015 11:14
An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
Betreff: [qvto-dev] QVT13-69 List and Dict Class/DataType confusion
Hi
Adolfo questions the more explicit prohibition of instance creation in the rephrasing of:
QVT 1.2 8.2.1.12 Helper:
However it is illegal to create or update object instances within a helper operation except for pre-defined types like sets, tuples, and for intermediate properties.
by
QVT 1.3 proposal:
A helper may modify but not create Class instances. A helper may modify mutable DataType values such as List or Dict.
A helper or query may create mutable DataType values such as List or Dict or immutable DataType values such as Tuple, Set or String
I think that the new words are clearer but equivalent.
The prohibition ensures that all object creation is internally visible to 'resolve' which considers only mappings and not helpers.
Anyone agree/disagree?
REgards
Ed Willink