Community
Participate
Working Groups
Maintaining the list (or worse set) of output objects solely to identify the typically one orphan object that will be the output root is rather expensive. Analysis of the QVTs mappings can identify many if not all created objects that are guaranteed to acquire a container avoiding the need to accumulate them. Objects whose containment cannot be guaranteed may be interesting to the programmer since they may represent bugs. Using QVTa, 'RealizedVariable' can be purely create, with a separate AS element/attribute controlling whether creation needs to contribute to potential orphan registration.
Resolving the incremental maintenance of the per-model potential orphans/roots list/set makes reducing their size very desirable.... --- For QVTr/QVTc...QVTm mappings, typical programming creates and contains within the same mapping so that a very high proportion of guaranteed containments can be identified. Once automatically partitioned, the distinct creation micro-mappings mean that containment cannot be guaranteed locally, but the shared trace objects enable the tightly coupled micromappings to be identified. Only a little extra complexity is incurred if done in partitioner, but thereafter a new analysis is needed to rediscover the the tightly coupled micromappings. For independently partitioned ocl2qvtp micromappings, there is no strong trace object, and output objects are very weakly typed before casting. Identifying which outputs are guaranteed to be contained may not be profitable. However prior to partitioning, the CS2AS.ocl makes many guaranteed containments clear. --- A new QVTi-level analysis is not attractive since the trace objects are weak. Computing a QVTs RealizedVariable.isContained during partitioning and propagating it through QVTi is fairly easy. Adding a QVTp RealizedVariable.isContained for use by ocl2qvtp is less desirable and becomes unnecessary once ocl2qvtp re-uses the QVT-level partitioning. --- There will often be at least one potential root, so the per-model collection of potential roots/orphans cannot be eliminated. We probably need per-model configurable behaviours. For debug: track all objects as potential roots/orphans. Not-saved middle: track no objects as potential roots/orphans. Otherwise: track only not-isContained objects as potential roots/orphans. --- This may not be the appropriate place to optimize the middle model. If it is saved as an output, it must be a normal model. If it isn't we can optimize. Not maintaining a potential roots/orphans is just an optimization that may be totally superseded by optimizing away middle objects altogether or folding them into optimized source objects. See Bug 507391.
