DGDanforth wrote:...but as you say, this is a hack anyway.
My original suggestion was a 'hack' with the dual purpose of having Doug test if it solved his problem, and, if so, of allowing him to modify his private installation if we decide not to put a solution into the official build. At that time I did not know how many different
sources of the
Restore call we needed to consider, so an INTEGER variable (called
src) was appropriate. We now understand that only two paths need to be distinguished.
I have suggested four refinements to this hack:
1 - Change the type to BOOLEAN
2 - Change the variable name (Dougs name is even better)
3 - Move the variable to Views
4 - Document it.
Is it still a hack? We might have different opinions. But if it is we should probably either NOT include it, or make further improvements.
Waiting for "somebody with more knowledge ... (to) provide a better solution" seems unrealistic. We are the best experts actively working in this area, and should decide on the solution to adopt now. Of course it is possible that a better solution may be found by a new expert, but that is true of every line in the framework, not just this one. When it is found we will then decide what to do about it.
The current proposal not only "cannot do any harm to existing views", it cannot provide "possible incompatibilities" with a later "solution to the underlying problem"; if indeed there is an underlying problem.
So, for me, treating this as a normal new Feature is a better approach than creating and publishing a new category of hidden, undocumented, "smart-hack".