Parameterization: onChange() should invalidate cache, and not immediately execute precompute()
|Status:||Backlog||Start date:||22 Apr 2016|
This is not only for elegance, but improves functionality: Currently, an exception is thrown whenever one parameter is set to a geometrically impossible value. However, a user or a fit may be in the course of changing several parameters. It may happen that the final value of parameter 1 is inconsistent with the initial values of parameters 2..N though it will be consistent with their final values. In such a case, no exception should be thrown.
Implementation is straightforward, and concerns only a few lines of code, but the following must be decided first: How to trigger precompute() if not through onChange()?
Solution 1: Test for cache status at the start of evaluate_for_q(..). Drawback: evaluate_for_q(..) is 'const', and runs multi-threaded. precompute() is not 'const' and not thread-safe. Could be solved by blocking the threads during precompute(). Too unelegant in my opinion.
Solution 2: Caller must call precompute() before launching the multithreaded evaluation. For safety, evaluate_for_q(..) tests nevertheless if the cache is up-to-date, else throws a BugReportException.
#2 Updated by wuttke over 4 years ago
- Status changed from Rfc to Sprint
- Assignee set to wuttke
- Target version set to Sprint 31
- each thread has it's own copy of sample parts, so threading will not be an issue
- and if were: it is perfectly valid for a cache to be declared mutable (that's actually the only case that comes to my mind where 'mutable' is good idea)
- since the cache is totally the responsibility of the object containing it, it ought to handle it himself (option 2 would export knowledge about existence of the cache to the caller)