[pivot] Rationalize XXXTables / XXXmetamodel

[eclipse-ocl-bot]

| --- | --- |
| Bugzilla Link | 581543 |
| Status | NEW |
| Importance | P3 normal |
| Reported | Feb 17, 2023 01:53 EDT |
| Modified | Aug 28, 2023 03:23 EDT |
| Depends on | 577825 |
| Blocks | 365447, 574430 |
| See also | 578199, 577889, 581851, 510503 |
| Reporter | Ed Willink |

Description

From Bug 578199.

OCLmetamodel/OCLstdlib provide the naive Pivot AS serialization.

PivotTables/OCLstdlibTables provide the added value AS literals and inheritance.

Why do we have both? Seems like we should merge the serialization to make the Tables complete.

---

After fixing a bug whereby the CG for an "excluding" call lacked an asOperation, test_let_implies_let_implies fails with an UOE for EcoreExecutorPrimitiveType.getOwnedInvariants(). Clearly the run-time must be able to escalate to the full metmodel. For now the test is suppressed.

[eclipse-ocl-bot]

By Ed Willink on Feb 17, 2023 03:31

The distinction between AbstractExecutorClass and (Pivot)ClassImpl is the inheritance of AbstractInheritance - the optimized but incomplete class tables.

Possible progress:

Step 1: change inheritance of AbstractInheritance to a delegation so that AbstractInheritance can be used in similar ways by both AbstractExecutorClass and ClassImpl.

Step 2: flesh out AbstractInheritance to a full flat class model and maybe rename as FlatClass.

Step 3: thin AbstractExecutorClass etc to nothing, possibly just variant constructors for ClassImpl etc.

Step 4: XXXmetamodel is obsoleted by XXXTaables/Support.

[eclipse-ocl-bot]

By Ed Willink on Feb 25, 2023 03:16

We nominally support three levels of execution aiming to avoid the overheads of full metamodels, for trivial executions such as "true" or "a.name".

But interactively there is no lightweight parser so building the AS to evaluate "true" requires the full metamodels. The limited case of evaluating from a persisted AS still needs the built-in BooleanType to define the return type. Anything requiring a referredOperation/referredProperty/referredType needs the full metamodel.

After code generation we may execute much more optimum code so that it is only when e.g. oclIsKindOf needs the type system that the lightweight XXXTables structures can be used without a full AS metamodel or PivotMetamodeManager.

It seems that the additional 'lightweight' metamodel structures attempting to use EClass without an AS Class creates undue complexity. Much better to have a single set of efficient structures.

(Might even be possible to phase out the EcoreExecutorManager.)

[eclipse-ocl-bot]

By Ed Willink on Feb 25, 2023 03:33

(In reply to Ed Willink from comment #2)

It seems that the additional 'lightweight' metamodel structures attempting
to use EClass without an AS Class creates undue complexity. Much better to
have a single set of efficient structures.

A problem arises with e.g. EvaluateNameVisibilityTest4.test_container_navigation where we evaluate "self.oclAsType(Tree)" using the Fruit metamodel, which is genmodelled as traditional Ecore without the corresponding FruitTables.java.

Options:

1. as now, work with just Ecore structures

2. embed a variant of FruitTables.java as part of the consumer CG support class

3. generate a shared FruitTables.java

4. could be a command line option wrt 2) but has difficulties wrt API stability of a shared file and uncertanty as to which consumer regenerates it.

[eclipse-ocl-bot]

By Ed Willink on Mar 24, 2023 05:55

The work on ewillink/581543 is pretty promising eliminating Executor* but attempting to have a sensible ClassImpl.flatClass cache analogous to CompleteClassImpl.flatClass fails because e.g. Real and Integer have Pivot and Oclstdlib contributions making use of the lightweight ExecutporStandardLibrary and so the ClassImpl.flatClass cache impossible.

Work suspended.

Bug 577825 is needed to merge at least OCLstdlib into Pivot and possibly OCLMetamodel into PivotTables as well.

[eclipse-ocl-bot]

By Ed Willink on Mar 24, 2023 06:56

(In reply to Ed Willink from comment #4)

Bug 577825 is needed to merge at least OCLstdlib into Pivot and possibly
OCLMetamodel into PivotTables as well.

Except that it is the use of regular Model/Package/Class etc in PivotTables that makes the regular Model/Package/Class in OCLmetamodel redundant.

[eclipse-ocl-bot]

By Ed Willink on Jun 03, 2023 02:50

This is progressing really badly; variously trying to jump too fast to the solution and getting 'old' classes muddled with 'new' ones.

The http://www.eclipse.org/OCL/ASMetamodel and http://www.eclipse.org/OCL/ASLibrary annotations should inhibit unwanted 'old' loads.

Step 1. Create model-gen/Pivot.oclas comprising precisely the merge of model/PivotStructural.ecore, model/Pivot.ocl and model/OCL-2.5.oclstdlib. Inconsistencies should be resolved.

Step 2. Achieve round-trip perfection between model-gen/Pivot.oclas and model-gen/Pivot.ecore. Iterations will need to map to EAnnotated EOperations.

Step 3. Refine GenmodelReloader to load a thin model/Pivot.genmodel and store as model-gen/Pivot.genmodel

Step 4. Support generation of PivotTables+PivotSupport from model-gen/Pivot.genmodel and the richer model-gen/Pivot.ecore.

Step 5. Delete/redirect OCLstdlibTables.

Step 6. Delete/redirect OCLstdlib, OCLmetamodel.

[eclipse-ocl-bot]

By Ed Willink on Jun 03, 2023 03:50

(In reply to Ed Willink from comment #6)

Step 1. Create model-gen/Pivot.oclas comprising precisely the merge of
model/PivotStructural.ecore, model/Pivot.ocl and model/OCL-2.5.oclstdlib.
Inconsistencies should be resolved.

No. Loading *.ocl and/or *.oclstdlib requires an OCL parser that loads the 'old' classes causing confusion. So use the already parsed models; model-gen/Pivot.oclas and model-gen/OCL-2.5.oclas.

[eclipse-ocl-bot]

By Ed Willink on Jul 10, 2023 02:43

(In reply to Ed Willink from comment #6)

Step 2. Achieve round-trip perfection between model-gen/Pivot.oclas and
model-gen/Pivot.ecore. Iterations will need to map to EAnnotated EOperations.

There is some fairly magic code that maps ocl::String to ecore::EString and even more magic for ocl::Boolean to ecore::EBoolean/EBooleanObject. Any change disrupts this magic and a few tests fail. The mapping was originally introduced before behaviouralClass was supported. Now the Pivot doesn't really care which is used, but Ecore must use EString and humans prefer unqualified String.

In Ecore we can use an EAnnotation to mark an EString as really String.

In OCLinEcore we use the Ecore spelling unless there is an EAnnotation. This means that a traditional Ecore file viewed in OCLinEcore will show EString rather than String; arguably a good change.

[eclipse-ocl-bot]

By Ed Willink on Jul 26, 2023 03:15

(In reply to Ed Willink from comment #6)

Step 2. Achieve round-trip perfection between model-gen/Pivot.oclas and
model-gen/Pivot.ecore. Iterations will need to map to EAnnotated EOperations.

Quite a few EAnnotations gets us very close but the OCLstdlib roundtrip test reveals that once we use a single Orphanage entry point for all Collection specializations, we find that the superclasses of specializations are defective. Some specialized collections are created before their generic is fully initialized. A new dependency analysis for the Xtend-generated OCLstdlib solves that but the superClasses() > 0 assertion fails for OCLstdlibTables.

The operation+class templated collection of tuples for product() requires quite precise dependencies that are not respected by naive heuristics. The nested class grouping to avoid 64k limits is inflexible. Much better to initialize in as many functions as necessary with initializations accurately dependency ordered.

Since we are trying to merge OCLstdlib and OCLstdlibTables migrate the better OCLstdlib analysis for use by OCLstdlibTables too.

[eclipse-ocl-bot]

By Ed Willink on Aug 18, 2023 03:18

(In reply to Ed Willink from comment #6)

Step 2. Achieve round-trip perfection between model-gen/Pivot.oclas and
model-gen/Pivot.ecore.

testOCLstdlibRoundTrip, testOCLstdlibASRoundTrip , testPivotRoundTrip, testPivotASRoundTrip all pass.

Since we are trying to merge OCLstdlib and OCLstdlibTables migrate the
better OCLstdlib analysis for use by OCLstdlibTables too.

Same SynthesisSchedule used for both. OCLstdlib and Pivot models regenerate satisfactorily.

[eclipse-ocl-bot]

By Ed Willink on Aug 19, 2023 06:38

(In reply to Ed Willink from comment #6)

Step 3. Refine GenmodelReloader to load a thin model/Pivot.genmodel and
store as model-gen/Pivot.genmodel

At last something easy. GenmodelReloader just needs distinct output genmodel/ecore command elements. The final Pivot.ecore can now be in model-gen.