...so I assumed that the condition() was something that operated independently of the functions.
From the code given, I would say it's a fairly safe assumption because it would be bad form for x() to change condition() while it can be executed from both outside and inside of the loop.
The problem is that x() ends up controlling the loop, rather than the loop controlling itself. The encapsulation of the x() functionality isn't very well defined if x() sets condition() for the loop, and can be executed inside of the loop and independent of it as well. The loop would end up being dependent on some logic that's occurring in x(), which determines whether or not it should execute y() and, subsequently, x() again. It seems awkward that way.
The counter analogy was simply supposed to show what the loop might have looked like if condition() had been based on some counter value. The pre-execution of x() would likely have required presetting the loop's counter to reflect the first iteration outside the loop.
It's hard to say which way, of all the methods discussed, would be the best, not knowing what's in x() or y(), but I guess that's my point. In a perfect coding world, the loop shouldn't have to know or depend on knowledge of what's in x() or y() to be able to run properly. |
