Community
Participate
Working Groups
Build Identifier: CVS Head of 2010-11-10 Two desirable OCL features need this functionality: 1) https://bugs.eclipse.org/bugs/show_bug.cgi?id=251621 (hidden opposites) 2) https://bugs.eclipse.org/bugs/show_bug.cgi?id=323223 (impact analyzer) Attached is a bundle that defines an interface for opposite end finding together with a default implementation based on a cross reference adapter. Additionally, the bundle makes the allInstances() scope pluggable and consistent with reverse / opposite lookups. Reproducible: Always
Created attachment 182938 [details] org.eclipse.ocl.ecore.opposites bundle Bundle implementing desired functionality
Partial response to avoid confusing specification and implementation details: One of my discomforts with an oppositeRoleName tag/comment/annotation came when I considered multiplicity/unique/ordered. In my unexercised QVT experiment, I had taken the pragmatic view that a hidden opposite containment had [0..1] multiplicity and a non-containment [0..*] {unique, !ordered}. I instinctively realized that my solution was inadequate, but never really analyzed the problems mainly because I didn't then understand the simple OCL philosophy underlying its obfuscated exposition. 1) Implicit/navigation disambiguation A major problem arises when analyzing a.b.c a.b->c in which b is a hidden opposite. Static knowledge of the upperbound multiplicity of b is needed to disambiguate object-navigation/implicit-collect or collection-navigation/implicit-collection. (I assume you do not want to have to do dynamic data-dependent disambiguation). 2) Implicit-collection disambiguation Selection of the implicit-collection kind is vague in the spec; two mentions of a Set of unit content, and one mention of a Bag of empty content. I have now pretty much dismissed my idea of using the singleton unique/ordered characteristic to use the modelled collection kind, since I think this is just too dangerous; users will not know their meta-model that well and some misunderstandings will not be diagnosed. Something unambiguous is needed and implicit Set (2 mentions in the spec) is better than implicit Bag (one mention). The differing defaults in EMOF/Ecore will not matter and there is no missing information needed to select the implicit-collection kind. Therefore it is necessary to know whether the upperbound is greater than 1. An oppositePropertyMany would do for syntax disambiguation. 3) Collection navigation More generally when analyzing the above to select the appropriate Collection operations, the unique and ordered properties are required. Ed suggested that a UML association is always unique, but I'm not convinced. The association is unique but there may be repeated target elements. So at least oppositePropertyOrdered and perhaps oppositePropertyUnique are also required. ---- I think that for completeness oppositePropertyUpper (default 1), oppositePropertyLower(default 0), oppositePropertyUnique (default true), oppositePropertyOrdered (default false) should be provided. NB. The defaults in Ecore are the Ecore defaults. The corresponding MOF serialisation should have the different UML defaults.
plugin I don't think 18kB merits an extra plugin. I think an addition o.e.o.ecore.opposites can be accommodated in the same way as o.e.o.ecore.delegate was added. Since 'delegate' was singular, I suppose 'opposite' should be singular too. Please provide future patches as part of 251621 since this is a prerequisite, and as an OCL, rather than EMF contribution, it can have combined IP approval. (If the author agreements are significantly different then IP approval may merit separate Bugzillas after all.) (Once I move this to o.e.o.ecore.opposite, there are 4 @since's to sort out.) ExtentMap The class documentation is thin. The UnsupportedOperation reasons have not been updated since the cut and paste. Looking at the old code, it seems that we have no Extent API class, just an exemplary LazyExtentMap. I think your new ExtentMap should at least extend LazyExtentMap and perhaps ExtentMap should beintroduced as a new sub-Map API for the thinner useful API. This could temporarily extend Map with a deprecation to faciltate a migration to the thinner interface. The Extent API is something that we should try to share with Dresden OCL, so perhaps we defer it now and introduce it in 4.0.0. When extending LazyExtentMap perhaps the added code is so trivial that you can use the existing policy of anonymous classes for concrete LazyExtentMaps. allInstances You might want to consider fixing at least Bug 329389 and possibly Bug 327386. PROPERTY_OPPOSITE_ROLE_NAME_KEY Javadoc consistently references this is in EcoreEnvironment although it is in OppositeEndFinder. Many more comments coming on Bug 251621
This has been merged in Bug 251621. *** This bug has been marked as a duplicate of bug 251621 ***
Closing DUPLICATEs
