OppositeEndFinder injection (#100)

[StephanErb]

Currently, OppositeEndFinder objects of specific subclasses (such as Query2OppositeEndFinder) are obtained throughout the code. As we keep seeing issues with the current query2 implementation, changes were performed that now additionally use DefaultOppositeEndFinder as implementation in some places (see, e.g., http://lists.furcas.org/pipermail/furcas-discussion/2011-March/000185.html). This runs danger of creating major inconsistencies.

We need a clean way of injecting a consistent OppositeEndFinder or a corresponding factory into a FURCAS implementation.

[StephanErb]

Stephan Erb ([email protected]) wrote on 2011-03-15 11:52:48

The idea should be to never instantiate a custom OppositeEndFinder but to always require one within the constructor. An appropriate OEF can be constructed within the editor and injected all the way down. The IMP Editor tries to stick to this schema.
 
Classes known to still instantiate a custom OEF (hidden in the TCSSpecificOCLEvaluator):
 * PrettyPrinter
 * ShortPrettyPrinter
 * ContentAssist
 
However, there are some special cases where we might want a specific OEF that only operates on the current resource set. For example, it might not always be wanted to find all TextBlocks but it is often sufficient to just find the one within the current textual view. I believe that the change performed by Sebastian falls into this category. 

[StephanErb]

Axel Uhl ([email protected]) wrote on 2011-03-15 12:10:45

(In reply to comment #1)
> The idea should be to never instantiate a custom OppositeEndFinder but to
> always require one within the constructor. An appropriate OEF can be
> constructed within the editor and injected all the way down. The IMP Editor
> tries to stick to this schema.
> 
> Classes known to still instantiate a custom OEF (hidden in the
> TCSSpecificOCLEvaluator):
>  * PrettyPrinter
>  * ShortPrettyPrinter
>  * ContentAssist
 
I've found usages of Query2OppositeEndFinder.getInstance() in AbstractGrammarBasedEditor, CtsDocument and LinkHelper. What about those?
 
> However, there are some special cases where we might want a specific OEF that
> only operates on the current resource set. For example, it might not always be
> wanted to find all TextBlocks but it is often sufficient to just find the one
> within the current textual view. I believe that the change performed by
> Sebastian falls into this category.
 
Good. Then I think there should be a useful comment that makes this thought explicit whenever an explicit non-injected selection of an OEM implementation is made.