DelegatingOperator puts name translations of local variables into the scope

[gkronber]

The DelegatingOperator (and thus the CombinedOperator) puts name translations for all it's VariableInfos into the scope. However since (optional) local variables of the CombinedOperator are not accessible via scopes for the sub-operators this behavior is not 100% consistent.

This defect didn't lead to errors yet however it looks like a possible cause for future problems.

[swagner]

Yes, that's true.

We can fix this behavior by automatically injecting and removing local variables into the scope when applying a DelegatingOperator. Right?

However, local variables of operators cause troubles. The original idea for local variables was to be able to have some kind of static parameterization of operators in order to mimic literals passed as parameters. Together with the ongoing thoughts to refactor the whole operator calling mechanism (keyword "call objects") I plan to remove local variables at all in the future and to replace them by constant objects that can be defined as actual parameters when calling an operator.

[gkronber]

Replying to swagner:

Yes, that's true.

We can fix this behavior by automatically injecting and removing local variables into the scope when applying a DelegatingOperator. Right?

Yes, however as you also state below this doesn't match the current design. A pragmatic solution is to create a translation only when the local-flag of the VariableInfo is false.

[swagner]

Well, I'm not quite sure about that. Just creating translations for non-local variables would break variable lookup in sub-operators when trying to fetch a variable that was declared as local in the responsible DelegatingOperator. Therefore local variables would not be useable in DelegatingOperators. So I think the lesser evil is to inject local variables.

[gkronber]

Replying to swagner:

Well, I'm not quite sure about that. Just creating translations for non-local variables would break variable lookup in sub-operators when trying to fetch a variable that was declared as local in the responsible DelegatingOperator. Therefore local variables would not be useable in DelegatingOperators. So I think the lesser evil is to inject local variables.

Oops yes, didn't think about that! It feels better to put the 'local' variable into the scope anyway. It's actually natural to have a local variable of a combined-operator available in the sub-operators.

[swagner]

Ok, then I will implement it that way.

[swagner]

Fixed in r113

[swagner]

Milestone 3.0 deleted

[swagner]

Milestone Iteration 0 deleted

[swagner]

Milestone Current deleted