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