Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351512

Summary:	[pivot] oclAsSet() malfunctions as a collect body
Product:	[Modeling] OCL	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	OCL Inbox <mdt-ocl-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	3.2.0
Target Milestone:	M4
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Ed Willink

2011-07-08 02:40:09 EDT

Using Ecore.ecore, select EObject

Evaluating:
eOperations.eType.oclAsSet().name
Results:
'EClass'
'EBoolean'
'EResource'
'EObject'
'EStructuralFeature'
'EReference'
'EEList'
'ETreeIterator'
'EEList'
'EJavaObject'
'EJavaObject'
'EBoolean'
'EJavaObject'

But

Evaluating:
eOperations->collect(eType)->collect(oclAsSet())->collect(name)
Results:
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'
'EObject'

Why the difference?

Comment 1 Ed Willink

2011-11-09 05:02:05 EST

eOperations->collect(eType)->collect(c : EClassifier | c.oclAsSet())->collect(name)

works and

eOperations->collect(eType)->collect(self.oclAsSet())->collect(name)

reproduces the problem. Looks like an implicit source problem.

Comment 2 Ed Willink

2011-11-10 05:13:19 EST

The problem is that the implicit collect did not flatten the Bag<Set<>> and so the subsequent name property had to search out to self to find a name.

EssentialOCLLeft2RightVisitor.resolveOperationReturnType now flattens the return type declaration for collect.

Additionally some bit rot had set in and in M3, an implicit collect as a source was not flattened either. NavigationOperatorCSScopeAdapter.computeLookup fixed.

Tests added. Pushed to master.

Comment 3 Ed Willink

2013-05-20 11:36:05 EDT

CLOSED after a year in the RESOLVED state.