eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[cg] Support Complete OCL code generation and cached Operations #1734

Open eclipse-ocl-bot opened 1 month ago

eclipse-ocl-bot commented 1 month ago

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

Description

Attempting to make progress on cached operation returns for Bug 491264 highlights a major CG limitation.

Cached operation returns requires per-operation unique computations in the style of org.eclipse.qvtd.runtime.evaluation.ComputationConstructor. For QVTi these are currently just Function/Query instances with a well-defined Package and so a well-defined Java Class.

For OCL there is no real CG capability for Operations, just bodies of OCLinEcore artefacts. There should be an OCL counterpart to the QVTiCodeGenerator to convert a *.ocl document complements into a single Java class. This should force the reification of def'd Operations and def'd Properties making cached calls easy.

Simple test case. Fibonacci.ocl defines an add-on operation for ELong that is successfully generated without affecting Ecore.

Better test case. RoyalAndLoyal.ocl should be code generated either as an embedded enrichment of RoyalAndLoyal.ecore or as a separate complement to RoyalAndLoyal.ecore.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 30, 2016 11:41

This Bug, the overall complementing Java class.

(In reply to Ed Willink from comment #0)

def'd Operations

Bug 500520

def'd Properties

Bug 500521

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 31, 2016 08:51

Minor problem. How does the user configure a Java basePackagePrefix? Perjaps a configured model-to-prefix map. Can a Java-generated Complete OCL be called from Java-generated OCLinEcore. If so are there genmodel annotations to configure?

More major problem. How does virtual operation dispatch work? We need a dispatch table, which the OCLinEcore generator normally provides. Do we 'extend' an existing xxxTables? Do we generate a local xxxTables for the new operations?

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 31, 2016 09:04

Both problems go away if we have a generated operation registry, indexed by model/OCL package names, referencing whatever Java names the generator found appropriate/configured. The access of the registry can accommodate virtual dispatch to the correct entry.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 31, 2016 13:49

(In reply to Ed Willink from comment #3)

generated operation registry

This is kind of available via OCLinEcoreTables, but we need add-on snippets rather than complete tables since if two CompleteOCL Java classes are loaded they must be merged with a dynamic type system.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Jul 17, 2020 15:49

https://www.eclipse.org/forums/index.php/mv/msg/1104546/1830128/#msg_1830128 identifies a further use case. It would be nice to turn a Complete OCL document that complements e.g. UML into useable Java code, preferably with a semi polymorphic API.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Nov 16, 2021 15:18

Surely the problems go away if we generate a new Statics sub-package of XXXTables in which nested sub-packages per required class support the statics of that class?

This structure can support static/additional Complete OCL, Operations and Properties.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Dec 01, 2021 09:28

Big 577563 identofies that a nested EcoreTables package could avoid fudging some DataType references.