[pivot] Can a CollectionType-d element be null?

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 511992 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 09, 2017 12:38 EDT | | Modified | Feb 10, 2017 06:14 EDT | | See also | Gerrit change https://git.eclipse.org/r/90816 | | Reporter | Ed Willink |

Description

The current TypedElement.isRequired allows a CollectionType-d element to be null. But this is pretty suspect. Not supported by Ecore. Prohibited by UML. Not obviously useful in OCL.

If ElementUtil.isRequiredType is changed to enforce non-null CollectionType-d elements, 6 JUnit tests fail.

ocl.assertQueryTrue(null, "let s : Sequence(Integer) = null in s <> Sequence{5}");

could be rewritten as OclAny without losing the subtest. But

ocl.assertQueryFalse(null, "let s1 : Sequence(Integer) = null, s2 : Sequence(Integer) = null in s1 <> s2");

cannot. The Pivot.ocl

parameters : OrderedSet(Parameter) = operation?.ownedParameters

cannot easily avoid the null even if it is an error.

---

So even if a null Collection may not be persistable, it seems that a null value must be allowed where an expression type may be a CollectionType.

[eclipse-ocl-bot]

By Ed Willink on Feb 09, 2017 13:04

(In reply to Ed Willink from comment #0)

it seems that a null value must be allowed ... for ... a CollectionType.

The JUnit tests can be fixed by a [?]

ocl.assertQueryFalse(null, "let s1 : Sequence(Integer) = null, s2 : Sequence(Integer) = null in s1 <> s2");

ocl.assertQueryFalse(null, "let s1 : Sequence(Integer)[?] = null, s2 :\ Sequence(Integer)[?] = null in s1 <> s2");

But the UML 2.5 tests:

The 'LetVariable::CompatibleNullityForInitializer' constraint is violated for 'handlerBodyOutput : OrderedSet(UML::Actions::OutputPin) = self.handlerBody.oclAsType(UML::Actions::Action).output'\ The 'LetVariable::CompatibleNullityForInitializer' constraint is violated for 'protectedNodeOutput : OrderedSet(UML::Actions::OutputPin) = self.protectedNode.oclAsType(UML::Actions::Action).output'

The 'LetVariable::CompatibleNullityForInitializer' constraint is violated for 'realizingClassifierInterfaces : Set(UML::Interface) = allRealizingClassifiers->iterate(c : UML::Classifier[1]; rci : Set(UML::Interface) = Set{} | rci->union(c.allRealizedInterfaces()))'\ The 'LetVariable::CompatibleNullityForInitializer' constraint is violated for 'realizingClassifierInterfaces : Set(UML::Interface) = allRealizingClassifiers->iterate(c : UML::Classifier[1]; rci : Set(UML::Interface) = Set{} | rci->union(c.allUsedInterfaces()))'

Is it reasonable/desirable that a more heavily tool compliant UML WFR add the [?]'s

[eclipse-ocl-bot]

By Ed Willink on Feb 09, 2017 13:09

(In reply to Ed Willink from comment #1)

Is it reasonable/desirable that a more heavily tool compliant UML WFR add the [?]'s

No. The problem is caused by a too-simple isRequired computatin for:

x : X = y;

If X is a CollectionType without an explicit [?]/[1] it should default to the initializer.

Ideally ElementUtil.isRequiredType should be three-valued, adding a don't know.

[eclipse-ocl-bot]

By Ed Willink on Feb 10, 2017 05:20

(In reply to Ed Willink from comment #2)

Ideally ElementUtil.isRequiredType should be three-valued, adding a don't know.

3-valued CS2AS.isRequiredType added, ElementUtil.isRequiredType deprecated and not used.

EssentialOCLCS2AS could override for CollectionTypeCS, but a non-unity upper can be tested in the base implmentation to detect the irregular case of a lazy UML-style Set such as T[] that cannot be null. The fuller OCL declaration of Set(T[])[?] must be used if a totally null Collection really is wanted.

[eclipse-ocl-bot]

Feb 10, 2017 06:14

New Gerrit change created: https://git.eclipse.org/r/90816