eclipse-ocl-bot
commented
1 month ago By Axel Uhl on Dec 08, 2010 08:17
(In reply to comment #100)
The com.google stuff is in Orbit, so you can install Orbit, but it should appear automatically if you install Xtext or MDT/OCL Examples.
Thanks for the hint. Now I can build the patch.
First a few minor issues:
-
Is there any specific reason you didn't apply the DI pattern to the extent map, e.g., in EcoreEvaluationEnvironment.createExtentMap(Object)?
-
Why does EcoreEvaluationEnvironment.createOppositeEndFinder still use "new DefaultOppositeEndFinder(...)? I assume it should be the same as in Ecoreenvironment.createOppositeEndFinder(), right?
-
createOppositeEndFinder() can probably be private as all constructors will have to invoke it due to the final declaration of oppositeEndFinder.
My major concern, however, is this: the injector is centrally configured for the single instance of the OCLPlugin, first come, first serve. This works for the two classes and their single instances OCLPlugin and OCLEcorePlugin. I don't (yet?) see how this would work if different clients of the OCLEcorePlugin wanted to use it with varying behavior. For example, some downstream bundles may want to use it with the DefaultOppositeEndProvider, some may want to use a Query2OppositeEndProvider. Similarly, some may want to use the LazyExtentMap, others the OppositeEndFinder-consistent ExtentMap.
With a single injector fixed by the first client to execute functionality that requires an injector (see your assertion "injector==null" in OCLEcorePlugin.createInjector) there can only be one system-wide configuration, not controllable by any contexts. Once created, an Injector can't be changed.
So, while the approach you chose to DI may work to manage the two different configurations required for Ecore vs UML, it most certainly doesn't work for different (potentially concurrent) runtime configurations of the single OCLEcorePlugin. This is why I really would like to have my overlladed constructors back.
| --- | --- | | Bugzilla Link | 251621 | | Status | CLOSED FIXED | | Importance | P3 enhancement | | Reported | Oct 21, 2008 17:08 EDT | | Modified | Sep 29, 2013 18:26 EDT | | Blocks | 318248 | | Reporter | Ed Willink |
Description
Bug #245586 started with a discussion of whether OCL should or should not assist QVT in using unnamed opposites in EMOF; the discussion was inconclusive and diverted to refactoring simpleNameCS to allow a derived simplePropertyNameCS which solves the problem within QVTr.
I have just started writing the missing validation constraints for QVTr using my IMP-based MDT OCL text editor. So I'm writing pure MDT OCL expressions referring to the QVT meta-model which is defined in Ecore/EMOF.
I find that I cannot use the implicit toLeadingLower name to navigate a default-named relationship, because AbstractEnvironment.findNonNavigableAssociationEnds is never called.
It is difficult to resolve this in a derived implementation because of a number of private methods.
I'll submit a patch that at least makes derivation possible once bug #242236 has settled. You can choose whether to accept a larger patch that performs the resolution as well.