[classic] Incorrect type inference for Bag::intersection() method

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 469156 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 02, 2015 11:01 EDT | | Modified | Jun 02, 2015 13:01 EDT | | Version | 6.0.0 | | Reporter | Sergey Boyko |

Description

For expression \ Bag{}->intersection(Bag{1});

OCL inferences the result type as 'Set(Integer)' while the correct type of result is 'Set(OclVoid)'.

Problem code is in org.eclipse.ocl.util.OCLStandardLibraryUtil::getBagTypeResultTypeOf(..) method.

[eclipse-ocl-bot]

By Ed Willink on Jun 02, 2015 11:10

The type of Bag{} is ill-defined and I came up with a solution for OCL 2.4 that is compatible but horrible.

The much simpler solution is that Bag{} is Bad(OclVoid) so that the library search looks for the common type of Bag(OclVoid) and Bag(Integer).

So Set(Integer) is correct.

But I am surprised that the classic Ecore gets this right. And I'm surprised that you're reporting the bug. Are you seeing a regression?

Set(OclVoid) is most certainly not correct, since "1" is not assignable to OclVoid.

[eclipse-ocl-bot]

By Sergey Boyko on Jun 02, 2015 11:11

(In reply to Ed Willink from comment #1)

The type of Bag{} is ill-defined and I came up with a solution for OCL 2.4 that is compatible but horrible.

The much simpler solution is that Bag{} is Bad(OclVoid) so that the library search looks for the common type of Bag(OclVoid) and Bag(Integer).

So Set(Integer) is correct.

But I am surprised that the classic Ecore gets this right. And I'm surprised that you're reporting the bug. Are you seeing a regression?

Set(OclVoid) is most certainly not correct, since "1" is not assignable to OclVoid.

[eclipse-ocl-bot]

By Sergey Boyko on Jun 02, 2015 11:15

(In reply to Ed Willink from comment #1)

The type of Bag{} is ill-defined and I came up with a solution for OCL 2.4 that is compatible but horrible.

The much simpler solution is that Bag{} is Bad(OclVoid) so that the library search looks for the common type of Bag(OclVoid) and Bag(Integer).

So Set(Integer) is correct.

But I am surprised that the classic Ecore gets this right. And I'm surprised that you're reporting the bug. Are you seeing a regression?

Set(OclVoid) is most certainly not correct, since "1" is not assignable to OclVoid.

No, 'Set(Integer)' is not correct. OCL defines '- (s : Set(T)) : Set(T)' as follows:\ The elements of self, which are not in s.

Elements of 'self' are of OclVoid type so there's no chance for them to become of Integer type.

[eclipse-ocl-bot]

By Sergey Boyko on Jun 02, 2015 11:34

(In reply to Sergey Boyko from comment #3)

(In reply to Ed Willink from comment #1)

The type of Bag{} is ill-defined and I came up with a solution for OCL 2.4 that is compatible but horrible.

The much simpler solution is that Bag{} is Bad(OclVoid) so that the library search looks for the common type of Bag(OclVoid) and Bag(Integer).

So Set(Integer) is correct.

But I am surprised that the classic Ecore gets this right. And I'm surprised that you're reporting the bug. Are you seeing a regression?

Set(OclVoid) is most certainly not correct, since "1" is not assignable to OclVoid.

No, 'Set(Integer)' is not correct. OCL defines '- (s : Set(T)) : Set(T)' as follows: The elements of self, which are not in s.

Elements of 'self' are of OclVoid type so there's no chance for them to become of Integer type.

Excuse me, this comment relates to bug 469157.

However for this bug similar considerations apply.

[eclipse-ocl-bot]

By Ed Willink on Jun 02, 2015 11:38

Bug 469157 has been marked as a duplicate of this bug.

[eclipse-ocl-bot]

By Ed Willink on Jun 02, 2015 13:01

(In reply to Sergey Boyko from comment #0)

OCL inferences the result type as 'Set(Integer)' while the correct type of result is 'Set(OclVoid)'.

The vagueness of OCL 2.0/2.2 may allow this as an interpretation.

This is Issue 12953 resolved in a needlessly complicated way in OCL 2.3. Issue 19612 raised for the simpler solution. Both will give Set(Integer).

Public text: http://www.omg.org/issues/issue12953.txt