Free cookie consent management tool by TermsFeed Policy Generator

Opened 14 years ago

Last modified 11 years ago

#1361 assigned defect

Missing event deregistration for parameter values

Reported by: cneumuel Owned by: swagner
Priority: lowest Milestone: HeuristicLab 4.0
Component: Parameters Version: 3.3.2
Keywords: Cc: abeham, mkommend, gkronber

Description

A GeneticAlgorihm registers ValueChanged events for some parameter-values, but does not deregister them when the values are replaced.

Change History (9)

comment:1 Changed 14 years ago by cneumuel

  • Status changed from new to accepted

comment:2 Changed 14 years ago by cneumuel

  • Owner changed from cneumuel to swagner
  • Status changed from accepted to reviewing

fixed in r5206

comment:3 Changed 14 years ago by swagner

  • Milestone changed from HeuristicLab x.x.x to HeuristicLab 3.3.3

comment:4 Changed 14 years ago by swagner

  • Cc abeham mkommend gkronber added
  • Owner changed from swagner to cneumuel

To be honest, I am not very happy with this change. We decided on purpose to skip appropriate event deregistration in these cases, as it would make parameter wiring even more complex and wiring is really a pain in the neck already.

The reason for this decision was that event deregistration should not be necessary. The objects used as values of the parameters in an algorithm are not used anywhere else. Therefore they are garbage collected after the parameter value changed and it does not matter that events registered on these objects are not deregistered. Of course this is no longer true, if you start referencing these value objects from outside the algorithm. But I think keeping such references should not be necessary and can be easily avoided by assigning clones to the parameters. Would that be a suitable solution?

If we decide to implement event deregistration as suggested in r5206, we would have to do it in every(!!!) algorithm and every(!!!) problem and not only in the GA. This is really a hell lot of work. Therefore I would prefer any less time-consuming solution.

Of course such a solution is not that neat and clean and we probably should schedule a refactoring of event registration/deregistration in the future but not for the 3.3.3 release. We should also avoid to add a quick fix such as r5206 without considering its impact on the whole framework in full detail. Therefore I suggest that we look for any other solution that will not affect the core framework in such a drastic way, that we revert r5206 and that we keep this ticket in the backlog so that we do not forget about it.

comment:5 Changed 14 years ago by abeham

I think we should look into different solutions like for example the one suggested in #1258. It's been on the last agendas, but unfortunately couldn't be picked up as there wasn't enough time.

comment:6 Changed 14 years ago by cneumuel

  • Owner changed from cneumuel to swagner

reverted in r5307 and r5308

Last edited 14 years ago by cneumuel (previous) (diff)

comment:7 Changed 14 years ago by cneumuel

  • Milestone changed from HeuristicLab 3.3.3 to HeuristicLab x.x.x

comment:8 Changed 14 years ago by swagner

  • Status changed from reviewing to assigned

comment:9 Changed 11 years ago by gkronber

  • Milestone changed from HeuristicLab 3.3.x Backlog to HeuristicLab 4.0.x Backlog
  • Priority changed from medium to lowest
Note: See TracTickets for help on using tickets.