Community
Participate
Working Groups
As per discussion in bug #261128, there was a couple of reasons that justified this class to be made internal. The EvaluationVisitorImpl class extends AbstractEvaluationVisitor which is part of the API. The concrete visitor adds nothing more visible to the client, so I would see nearly zero refactoring effort to expose it as API. MDT OCL design promotes using visitor composition, which is pretty useful for adding generic interception features. However, based on QVTo experience, I think it's more straightforward to use extension of this class to add a new evaluation functionality. Before suggesting a very small refinement of this class ;), just asking, would this be OK for MDT OCL?
Sorry for nagging ;), this enhancement seems to be quite important for the QVTo component. Thoughts? If it make sense I can provide a patch.
Sorry, Radek. You shouldn't have to nag. Yes, attach a patch, and I'll assess the damage ;-)
Created attachment 126448 [details] Expose EvaluationVisitorImpl I have moved the 'EvaluationVisitorImpl' class to 'org.eclipse.ocl' package, not sure if this is a good place for ...Impl class. You will decide ;) Additionally, I have added operation 'AbstractEvaluationVisitor.setEvaluationEnvironment(EvaluationEnvironment', which allows for switching evaluation environments as the evaluation moves accross stack frames. I can see the operations bellow create a nested evaluation environment along with a new visitor instance to perform a body evaluation. protected Object call(O, OCLExpression<C>, Object, Object[]); protected Object navigate(P, OCLExpression<C>, Object); To my understanding, the same could be done by using a shared visitor instance, setting the nested evironment to the visitor before the call and resetting to the original one after. This way we would ensure that eventual decorating visitors will get involved in body expressions evaluation, which does not seem to be the case know. What do you think?
Christian, could you please consider resolution of this bugzilla for M6 target?
Patch committed to HEAD (1.3 branch), with addition of @since tags where needed. Somebody forgot their API tooling set-up! ;-) (In reply to comment #3) > I can see the operations bellow create a nested evaluation environment along > with a new > visitor instance to perform a body evaluation. > protected Object call(O, OCLExpression<C>, Object, Object[]); > protected Object navigate(P, OCLExpression<C>, Object); > > To my understanding, the same could be done by using a shared visitor instance, > setting > the nested evironment to the visitor before the call and resetting to the > original one after. > This way we would ensure that eventual decorating visitors will get involved in > body expressions > evaluation, which does not seem to be the case know. > What do you think? Yes, that sounds like a good idea. It's definitely not good that decorators currently miss the nested environments. Please raise a separate bug for this problem.
Closing after over 18 months in resolved state.
