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

Bug 202611

Summary: Return value of EOperations with EList return type coerced to first element
Product: [Modeling] OCL Reporter: Artem Tikhomirov <tikhomirov.artem>
Component: CoreAssignee: Christian Damus <give.a.damus>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 1.1.0   
Target Milestone: 1.2.0   
Hardware: All   
OS: All   
Whiteboard:

Description Artem Tikhomirov CLA 2007-09-07 06:11:08 EDT 
E.g. someEPackage.eContents() gives first element only.

EcoreEvaluationEnvironment#getCollectionKind(ETypedElement) reasonably checks for isMany(), however, it doesn't work for operations with upperBound == 1 and return type of EList.

Related bug #183667
Comment 1 Christian Damus CLA 2007-09-10 11:47:39 EDT 
How is it that you are able to access the eContents() operation?  I wouldn't expect it to be available, as it isn't a "feature" of the EPackage class ... it's one of EMF's pseudo-features.

If the upper bound of the eContents() operation is defined as 1 but the type is EList, then it is modeled with eType == EEList (an EDataType).  OCL, in general, doesn't know what to do with EDataTypes because they don't support the definition of properties or operations.  However, in this case I would expect the EcoreEnvironment to re-interpret ecore::EEList as equivalent to ocl::Sequence.  If it isn't doing that, it should.  Or are you saying that it would work alright except for the changes introduced by bug 183667 (a regression)?
Comment 2 Artem Tikhomirov CLA 2007-09-13 08:41:01 EDT 
(In reply to comment #1)
> How is it that you are able to access the eContents() operation? 

EClassifier happens to have instance class, and EcoreEvaluationEnvironment#getJavaMethodFor resolved operation to java method.


> the EcoreEnvironment to re-interpret ecore::EEList as equivalent to
> ocl::Sequence. 

I would expect the same. It's not a regression of #183667, I believe, rather incomplete #getCollectionKind() logic.
Comment 3 Christian Damus CLA 2007-09-13 09:58:56 EDT 
(In reply to comment #2)
> EClassifier happens to have instance class, and
> EcoreEvaluationEnvironment#getJavaMethodFor resolved operation to java method.

I was actually wondering why it is that the parser recognized the existence of an eContents() operation in the first place, but I see now that EModelElement explicitly extends EObject, which explicitly models all of these eXyz() operations.  That's actually somewhat unfortunate, IMO.


> I would expect the same. It's not a regression of #183667, I believe, rather
> incomplete #getCollectionKind() logic.

That's good to know!
Comment 4 Christian Damus CLA 2007-09-20 14:09:26 EDT 
Fix committed to CVS HEAD (1.2 branch).
Comment 5 Christian Damus CLA 2007-09-21 12:01:06 EDT 
Fixed in MDT OCL 1.2.0 I200709211125 build.
Comment 6 Nick Boldt CLA 2008-01-28 16:38:48 EST 
Move to verified as per bug 206558.
Comment 7 Ed Willink CLA 2011-05-27 02:40:44 EDT 
Closing after over a year in verified state.
Comment 8 Ed Willink CLA 2011-05-27 02:42:01 EDT 
Closing after over a year in verified state.