eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[pivot] Resolve static OCLstdlib properties / oclType() confusion #2220

Open eclipse-ocl-bot opened 2 weeks ago

eclipse-ocl-bot commented 2 weeks ago

| --- | --- | | Bugzilla Link | 577902 | | Status | NEW | | Importance | P3 normal | | Reported | Dec 20, 2021 05:11 EDT | | Modified | Jan 02, 2022 07:32 EDT | | See also | 577887, 578010 | | Reporter | Ed Willink |

Description

Further to questioning why allInstances() is static, contrary to the OMG OCL spec, why are e.g. Collection.elementType/upper/lower etc static? supporting a JUnit test such as Sequence{'1', '2', '3'}->oclType().elementType that evaluates to String.

Clearly aCollection.elementType has different values for distinct collections so it cannot be a static property of the templated Collection.

Rather elementType, lower, upper are normal properties of untemplated CollectionType that can be accessed from the instance by ->oclType().elementType if oclType() is defined to return the specialized CollectionType. Optionally the normal properties of Collection could delegate to their oclType().

(This contrasts to Java where getClass() returns an unspecialized type which is a consequence of the late introduction of generics forcing use of erasures for legacy compataibility.)

The "static" has been used to support modeling at the wrong meta-level.

Once Collection.elementType/upper/lower etc are moved to CollectionType etc, we may find that typeValue is no longer needed to memento the 'wrong' type.

eclipse-ocl-bot commented 2 weeks ago

By Ed Willink on Jan 01, 2022 05:01

The 'tyeValue(In reply to Ed Willink from comment #0)

The "static" has been used to support modeling at the wrong meta-level.

Bug 578010 considers static in the context of Stereotype normalization.

Once Collection.elementType/upper/lower etc are moved to CollectionType etc, we may find that typeValue is no longer needed to memento the 'wrong' type.

"typeValue" is a bad spelling with an unhelpful type that promotes special case confusion.

It should be "boxedValue" with an Object type so that it represents the optionally statically folded value of an OCLExpression. (Optionally to allow lazy evaluation of potentially complicated iterations.)

An IntegerLitetalExp for "42" has a type of that is the PrimitiveType named Integer, and a boxedValue of a/the IntegerValue for 42.

A TypeExp for Person has a type that is the Class named Class, and a boxedValue that is a/the Class named Person.

Person.allInstances() is therefore able to have a Set(Person) rather than Set(OclAny) return since the source has a statically folded value.

eclipse-ocl-bot commented 2 weeks ago

By Ed Willink on Jan 02, 2022 07:32

Bug 577887 has fixed the spurioius static/wronf meta-level for allInstances, elementTypeetc.

This bug remains open to generalize typeValue as boxedValue.