[cg] Inconsistent meta-meta-type

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 577889 | | Status | NEW | | Importance | P3 normal | | Reported | Dec 19, 2021 05:06 EDT | | Modified | Mar 23, 2023 04:55 EDT | | See also | 581543 | | Reporter | Ed Willink |

Description

Introducing the BooleanType for Bug 577887 highlights a fudge in the \ test_oclType, test_oclTypes, test_oclType_Boolean tests so that when interpreted

e.g. 3.oclType().oclType()

is tested for PrimitiveType, but when CGed for Class.

While the meta-meta-types are hardly critical surely they should be consistent?

[eclipse-ocl-bot]

By Ed Willink on Dec 19, 2021 05:26

Debugging the oclType() class

Interpreted: 3 -> PrimitiveType:"Integer" -> Class:"PrimitiveType"

CGed: 3 -> EcoreExecutorType:"Integer" -> EcoreExecutorType:"Class"

'Just' need to make the EcoreExecutorType richer to avoid loss of the meta-meta-types.

The comment in EcoreIdResolver.getStaticTypeOfValue is:

// The direct CGed Executor has no eClass() so use getMetaclass()

Upgrade to a FIXME referencing this bug.

[eclipse-ocl-bot]

By Ed Willink on Dec 24, 2021 05:11

Probably closely related is that surely the meta-allInstances

BooleanType.allInstances() should return Set(Boolean}

Presumably the problem is that the built-in EcoreExecutorXXX instances of the Pivot / OCLstdlib java metamodels do not populate the model manager.

[eclipse-ocl-bot]

By Ed Willink on Jan 07, 2022 10:12

After returning the true metatype from oclType(), the absence of derived ExecutorCollectionType shows up for CGed execution. Add the four derived collection types and primitive types.

After fixing all the meta-type deductions to give e.g. BooleanType rather than Class, we have just one CG-only failure for: test_oclType_OclAny

ocl.assertQueryResults(null, "Set{null}", "null.oclAsType(OclAny).oclType().allInstances()");\

\ which variously gives Set{} for AnyType, rather than Set{null} for VoidType, or a CCE from VoidType to AnyType since oops VoidType does not extend AnyType.

The correct return requires a polymorphic dispatch for the metatype,

The no-CCE requires oclType to type wrt the common type, but...

Discussion moved to first comment of https://issues.omg.org/browse/OCL25-33 where it is demonstrated that the M2 conformances must mirror M1, so VoidType is-a AnyType.

[eclipse-ocl-bot]

By Ed Willink on Jan 08, 2022 01:34

Injecting AnyType between Class and DataType/VoidType/... hits pragmatic problems where a default visitDataType that dropped through to VisitClass now does visitAnyType. A few variations are differently painful.

Step back. Yes, allInstances() may be subject to polymorphic dispatch, but why does M2 need to morror M1. It could be that everything at M2 is a Class, except a couple of cherry-picked classes, such as OclAny. Over-use of M2 conformance is the CG bug.

[eclipse-ocl-bot]

By Ed Willink on Jan 08, 2022 03:50

Doh! The probelm is the statically determined return type of oclType().

At run-time aT.oclType() returns the metatype of aT; ie. Class named T.

At compile-time aT.oclType() returns the common metatype of all possible aT; ie Class named T.

But if aT is something better known such as "true" we need the common metatype of BooleanType and VoidType (and InvalidType) i.e. the Class named Boolean.

This may require that OclAny has two metatypes; the AnyType named OclAny when precisely OclAny, and a Class named OclAny when operating with compile-time generality.

[eclipse-ocl-bot]

By Ed Willink on Mar 23, 2023 04:55

The Bug 581543 work eliminates the duplication of ExecutorType etc. Inconsistency solved. However deleting/obsoleting 30 odd classes cannot realistically be API compliant. Must wait for major version.