Max wrote:Sure. What I'm saying is that I do not think it's the best... the wrong part of my reply ...
Was the right part where you wrote:We'd actually be changing more things.
I also don't care that much how much code is changed;
if it must be changed, then change it to what is best,
which may not necessarily be the minimum change.
If an asynchronous sched domain rebuild is needed inI still do not see a good reason why. IMO exceptions are acceptable.
some places, then consider just using it everywhere,
rather than providing two code paths to rebuild, one
sync and one async.
Ask not how we got here; ask where we should be.I'm not sure what you're referring to. There was no back an forth.
In particular, and in this specific case, having the
dual code paths really did make it a little more difficult
for me to understand the code, as evidenced by the back
and forth discussion on how to name the confusingly
similar functions. Such naming controversies are usually
a sign of code duplication or improper factoring.
That additional difficulty in understanding this codeTo be fair the fact that you had trouble understanding my code does
was a key factor in delaying my review of your code.
I'd look at it, my mind was glaze over, and I'd put
it aside for a few days. This happened repeatedly.
Fine code is like fine art ... spare, elegant, compelling
in its expression.