search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[cg] Support code generation of Complete OCL defined Operations #1735

Open eclipse-ocl-bot opened 2 hours ago

eclipse-ocl-bot commented 2 hours ago

| --- | --- | | Bugzilla Link | 500520 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 30, 2016 11:38 EDT | | Modified | May 04, 2022 08:20 EDT | | Blocks | 507628, 500519 | | See also | 500551, 500521, 534421 | | Reporter | Ed Willink |

Description

As part of Bug 500519 and Bug 491264 support code generation of operations originating from a Complete OCL def.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Sep 06, 2016 09:43

Add a transient capability to suppress caching.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Dec 09, 2016 06:22

In particular QVTi WFRs would like a joinNames utility operation.

If defined on Element, it is not generated although an attempt is made to insert it into Pivot.ecore.

Perhaps a static definition could easily be placed into XXXTables.java

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Dec 02, 2021 05:46

How? As for static properties in Bug 500521.

We start with an OperationId from which executor.getStaticOperationImplementation returns a LibraryOperation, for which the OCL code can be reified as a derived new ExecutorOperation.

This sensibly happens for all OCL-defined operations so that we have an OCL API. The existing Ecore embeddings can migrate so that they comprise nothing more than an OCL API conversion stub.

ExecutorOperation instances can be placed in any XXXTables so that we can easily accommodate foreign operations that lack their own Ecore code. If we have to duplicate a foreign operation in both XXXTables and YYYTables that is inelegant bloat but not a functional problem.