Open eclipse-ocl-bot opened 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
def'd Properties
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?
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.
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.
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.
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.
By Ed Willink on Dec 01, 2021 09:28
Big 577563 identofies that a nested EcoreTables package could avoid fudging some DataType references.
| --- | --- | | 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.