Context Navigation

#94 closed defect (duplicate)

Operators might overwrite existing aliases in the scope

Reported by:	gkronber	Owned by:	swagner
Priority:	low	Milestone:	HeuristicLab 3.3.0
Component:	Operators	Version:	3.0
Keywords:		Cc:

Description (last modified by gkronber)

Before applying the operator and possible sub-operators the name-translations of the operator are written to the scope. This overwrites existing bindings in the case when there is an existing translation from a->b and we insert a new translation from a->c.

This matches the expected behavior for the sub-operators namely that the 'more-direct' translations (in the scope-hierarchy) come first. However a 'clean' solution would restore the previous translation (a->b) when the operator removes it's own translations again.

This issue also doesn't seem to have serious effects yet however there might be problems in the future.

Change History (10)

comment:1 Changed 16 years ago by gkronber

Description modified (diff)
Summary changed from DelegatingOperator might overwrite existing aliases in the scope to Operators might overwrite existing aliases in the scope

This issue applies to all operators (OperatorBase and DelegatingOperator)

comment:2 follow-up: ↓ 4 Changed 16 years ago by swagner

Yes, again you are absolutely right.

The dilemma is that the aliasing mechanism is a (quite dirty) hack to make combined operators useable in the current architecture. I know that and I'm not proud of it ;-).

However, I don't think we need to fix this issue at the moment. The better idea is to refactor the whole operator architecture, as we already discussed in several sessions. Well, I think now time has come to create a ticket for that and to continue our discussion here in trac.

comment:3 Changed 16 years ago by swagner

Created ticket #95 as a master ticket for refactoring the operator architecture.

comment:4 in reply to: ↑ 2 Changed 16 years ago by gkronber

Replying to swagner:

However, I don't think we need to fix this issue at the moment. The better idea is to refactor the whole operator architecture, as we already discussed in several sessions. Well, I think now time has come to create a ticket for that and to continue our discussion here in trac.

Ok, there is also a related issue that I wanted to represent in a separate ticket. In light of ticket #95 I will refrain from that for now.