Bugzilla – Full Text Bug Listing
| Summary: | Lookup of ecore::-prefixed type names doesn't find EMF ecore types | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Axel Uhl <eclipse> | ||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ed | ||||
| Version: | 3.1.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
The problem stems from 9.4.1 [4] which I think Christian has endeavoured to implement accurately and from the very bad decision to re-use 'ecore' for OCL ecore. It keeps biting. In the context of A::B a reference to B::x is A::B::x. ::B::x is hidden. C++ solves this by allowing :: as a leading global scope indicator. Java avoids this by having a reserved java name and a habit of very long names so collisions do not occur in practice. Your solution provides a kind of package merge. B::x can be either A::B::x or ::B::x. This cannot be right, so -1. The current behaviour is correct but embarrassing. How serious is the problem? We seem to have survived for 3 years; the problem goes away with the Pivot model. Should we introduce a '::' global scope prefix? OMG Issue raised. Can we provide an alias for the hidden 'ecore' by registering with a different name? Can you arrange to use a different current context that avoids the ambiguity? Created attachment 189891 [details]
The patch again as attached file
The same patch as attached file
(In reply to comment #1) > Your solution provides a kind of package merge. B::x can be either A::B::x or > ::B::x. This cannot be right, so -1. The current behaviour is correct but > embarrassing. Not sure why you say it can't be right. It seems that the way type names are currently resolved is ambiguous. Not sure if this comes from the OCL spec, but I think the trouble comes from the fact that qualified type names are not always considered fully qualified. Does the OCL spec allow for partly qualified type names? However, I of course understand that there's no easy way to change *this* part of the implementation. That's why I was shooting for a more careful approach where behavior is only changed in case otherwise an error would result. > How serious is the problem? We seem to have survived for 3 years; the problem > goes away with the Pivot model. It currently disallows using OCL to talk about OCL in the presence of Ecore and trying to make reference to Ecore. This is a pretty serious restriction, we find. > Should we introduce a '::' global scope prefix? OMG Issue raised. Would that work before M6? > Can we provide an alias for the hidden 'ecore' by registering with a different > name? Is it possible to register with multiple names? If not, that would again be a bad incompatibility, I assume. '::' as global scope prefix then would be the better choice since compatible. > Can you arrange to use a different current context that avoids the ambiguity? Unfortunately not. We need a "self" context from the ocl::ecore package. (In reply to comment #3) > (In reply to comment #1) > > Your solution provides a kind of package merge. B::x can be either A::B::x or > > ::B::x. This cannot be right, so -1. The current behaviour is correct but > > embarrassing. > > Not sure why you say it can't be right. It seems that the way type names are > currently resolved is ambiguous. Not sure if this comes from the OCL spec, but > I think the trouble comes from the fact that qualified type names are not > always considered fully qualified. Does the OCL spec allow for partly qualified > type names? The OCL spec is, I think, very clear on this issue. A reference to a package is a reference to exactly one package and A::B hides B. So to adopt your solution would be to introduce a bug to avoid solving an inadequate behaviour. > > Should we introduce a '::' global scope prefix? OMG Issue raised. This is Bug 338376. > Would that work before M6? Very unlikely. My time is fully committed to the EclipseCon tutorial and necessary support for it. Maintenance of what I perceive to be mature code is very low priority. > > Can we provide an alias for the hidden 'ecore' by registering with a different > > name? > > Is it possible to register with multiple names? If not, that would again be a > bad incompatibility, I assume. '::' as global scope prefix then would be the > better choice since compatible. The package name resolution in the package registry is poorly defined and different for UML and Ecore bindings. It should be possible to add new aliases "Ecore" and "OCLEcore" to workaround the problem. This can probably be done by the user code constructing an 'OCL' with a package registry; or perhaps by a simple derived Environment.lookupPackage overload. If really necessary perhaps an additional poke-the-registry API function might help. The API should support the 'concrete syntax' extension for Complete OCL: import myName : 'namespaceURI' In the same way that XML imports are named by xmlns, model imports should be user-named. Closing WONTFIXes. Closing all bugs resolved in Indigo. |
If the context of an expression is an OCL type, such as from the ocl::ecore package, the context package of the EcoreEnvironment is reasonably set to that package. Now, if a type lookup needs to happen in AbstractOCLAnalyzer for a type coming from the EMF ecore package, the type lookup fails. This is because EcoreEnvironment.lookupClassifier doesn't expect there to be two packages of equal names (ocl::ecore with basic name "ecore" and EMF ecore with basic name "ecore") and so decides that a failed lookup in ocl::ecore should let the entire lookup fail. The following proposed patch still lets all OCL tests pass and additionally allows for successful fully-qualified type resolutions for EMF ecore::* types. ### Eclipse Workspace Patch 1.0 #P org.eclipse.ocl.ecore Index: src/org/eclipse/ocl/ecore/EcoreEnvironment.java =================================================================== RCS file: /cvsroot/modeling/org.eclipse.mdt/org.eclipse.ocl/plugins/org.eclipse.ocl.ecore/src/org/eclipse/ocl/ecore/EcoreEnvironment.java,v retrieving revision 1.10 diff -u -r1.10 EcoreEnvironment.java --- src/org/eclipse/ocl/ecore/EcoreEnvironment.java 25 Jan 2011 10:43:34 -0000 1.10 +++ src/org/eclipse/ocl/ecore/EcoreEnvironment.java 23 Feb 2011 14:37:47 -0000 @@ -389,8 +389,11 @@ } if (pkg != null) { - return EcoreForeignMethods.getEClassifier(pkg, lookup + EClassifier result = EcoreForeignMethods.getEClassifier(pkg, lookup .get(lookup.size() - 1)); + if (result != null) { + return result; + } } if ((currPkg == getContextPackage()) && (lookup.size() > 1)