[as2cs] Support non-trivial TypeExp

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 496810 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 27, 2016 04:39 EDT | | Modified | Jun 20, 2022 02:52 EDT | | See also | 546767, 548664, Gerrit change 194294 | | Reporter | Ed Willink |

Description

Forked from Bug 496768

Most of the OCL tooling uses a textual serialization of OCL expressions and so the EssentialOCL as2cs code is little used. The only usage is during 3 UML25LoadTests JUnit tests where CompleteOCLSplitter provides *.ocl files.

The QVTd tooling uses as2cs with a vengeance and so it is the QVTd usage that detects that the as2cs for TypeExp is very deficient. Most notably for oclAsType(Set(MyClass)) but generally for any of the TypeExp's that are not simple names.

? for test purposes we perhaps want an option for EssentialOCLDeclarationVisitor.visitExpressionInOCL to convert the AS tree rather than PrettyPrint it.

[eclipse-ocl-bot]

By Ed Willink on Jun 27, 2016 07:04

(In reply to Ed Willink from comment #0)

? for test purposes we perhaps want an option for EssentialOCLDeclarationVisitor.visitExpressionInOCL to convert the AS tree rather than PrettyPrint it.

The functionality is potentially there provided an EssentialOCLReferenceVisitor rather than BaseReferenceVisitor is in use.

[eclipse-ocl-bot]

By Ed Willink on Jun 27, 2016 07:18

(In reply to Ed Willink from comment #1)

The functionality is potentially there provided an EssentialOCLReferenceVisitor rather than BaseReferenceVisitor is in use.

WIP on branch ewillink/496810. There appear to be many test failures once OCLinEcore does not use PrettyPrinter.

[eclipse-ocl-bot]

By Ed Willink on Aug 08, 2016 05:52

(In reply to Ed Willink from comment #2)

WIP on branch ewillink/496810. There appear to be many test failures once OCLinEcore does not use PrettyPrinter.

Problem is that EssentialOCLReferenceVisitor overrides visitClass to bypass the inherited functionality that creates a TypedTypeRefCS to fall back to visitType that creates a TypeNameExpCS. And there is no vsitDataType to create a TypedTypeRefCS at all. The above deficiencies cause the Xtext serialiser to fail with an undiagnosed ISE.

It looks as if EssentialOCLReferenceVisitor must somehow have two different modes:

• expecting a Type declaration => TypedTypeRefCS
• expecting a Type expression => TypeNameExpCS

[eclipse-ocl-bot]

By Ed Willink on Aug 08, 2016 06:14

(In reply to Ed Willink from comment #3)

• expecting a Type declaration => TypedTypeRefCS
• expecting a Type expression => TypeNameExpCS

TypedTypeRefCS and TypeNameExpCS are very similar. Some of the differences are possibly bugs. However the main difference is that

TypedTypeRefCS has <...> template bindings\ TypeNameExpCS has (...) template bindings

This difference is fundamental. Leave ...ReferenceVisitor unchanged for declarations. Add a new ...ExpressionVisitor for TypeNameExpCS.

[eclipse-ocl-bot]

By Ed Willink on Oct 26, 2016 05:04

Structural evolution to introduce CS2AS.AbstractFactory pushed to master.

Actual changes still WIP on ewillink/496810.

[eclipse-ocl-bot]

By Ed Willink on Apr 26, 2019 07:02

Bug 546767 fixes a surprising number of bugs regarding TypeExp and nested collections allowing OCLinEcore-like declarations in QVTi.

Perhaps the core fixes may render the OCLinEcore override redundant now.

[eclipse-ocl-bot]

By Ed Willink on Jun 26, 2019 05:35

Bug 548664 special cases its way round the TypedTypeRefCS/TypeNameExpCS mess to support TemplateParameter literals.

[eclipse-ocl-bot]

By Ed Willink on Jun 19, 2022 03:23

3 years on the fixes/fudges seem adequate, but there is a nagging issue left. For the new Stereotype work, the synthesis of oclExtensions() in PivotHelper.createOperationCallExp seems to need

Type asArgumentType = asArgument instanceof TypeExp ? ((TypeExp)asArgument).getReferredType() : asArgument.getType();

This cannot be right. It seems that a bug in one place is being patched up elsewhere. OCLExpression should always return the type of its value.

Thus for IntegerLiteralExp a value the CGed Java could be

Integer anInteger = 42;

For TypeExp, that should be spelled TypeLiteralExp, the unboxed Java could be

java.lang.Class<?> aClass = Integer.class;

and is simplistically CGed as the boxed

org.eclipse.ocl.pivot.Class aClass = OCLstdlibPackage.Literals.INTEGER;

---

Perhaps the complexity is that OCL has stronger class types, whereas in Java all classes are Class which may have as many templates as appropriate. The stronger types are necessary to provide the narrower / friendlier templates API and the allInstnaces overload. It is BooleanType.allInstances() that computes true/false.

In 'JavaOCL' we could therefore write

PrimitiveType aClass = Integer.class;

Providing the stronger type for a TypeExp should cause no problem; it is just more precise.

---

Perhaps the problem is inconsistent boxing of Type objects.

---

Perhaps the problem is that OclStereotype is not a Class. Maybe the OCL standard library should use Stereotype and Class more directly rather than OclStereotye and OclType.

---

TemplateParameter causes difficulties since it is a Type but not a Class. Special handling is needed in:

EssentialOCLCSLeft2RightVisitor.resolveTypeExp\ createTypeExp.createTypeExp

Attempting to unify with the two variants of StandardLibrary.getMetaclass mostly works for Stereotype but not TemplateParameter.

---

Whatever. Get to the bottom of it.

[eclipse-ocl-bot]

Jun 20, 2022 02:52

New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/194294