Open eclipse-ocl-bot opened 2 weeks ago
By Ed Willink on Oct 16, 2020 15:10
See https://www.eclipse.org/forums/index.php/m/1833554/#msg_1833554 for further motivation and thoughts.
By Ed Willink on Dec 02, 2021 03:50
How?
Access/Representation:
We already have a PropertyId and an EcoreExecutorProperty, with an eFeature whose EAnnotation indicates isStatic. Could elaborate to a derived EcoreExecutorStaticProperty.
The 'same' static property might need to be independently represented in both XXXTables and YYYTables so we cannot just generate a Java static field. Must do executor.getStaticPropertyValue(staticPropertyId) to obtain the richer static value and executor.getStaticProperty(staticPropertyId) when the richer EcoreExecutorStaticProperty is required for meta-level activity.
Initialization:
The EcoreExecutorStaticProperty must create the correctly typed and initialized property on first access. Arbitrary parameteric type creation is hard, except that the initializer is presumably an OCL expression that can return a suitable value, or create a shadow object. This code could be CGed as a derived method of the new EcoreExecutorStaticProperty().
Mutation:
OCL / QVTd does not allow mutation of the static property, but QVTo does. Maybe behind the scenes QVTo has to keep doing EcoreExecutorStaticProperty.setValue() and must clone the shadow object in time. There are options for QVTo. Don't needto clutter OCL/QVTd unnecessarily.
| --- | --- | | Bugzilla Link | 500521 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 30, 2016 11:39 EDT | | Modified | May 04, 2022 08:20 EDT | | Blocks | 500519 | | See also | 500551, 500520, 534421 | | Reporter | Ed Willink |
Description
As part of Bug 500519 and Bug 491264 support code generation of properties originating from a Complete OCL def.