I would urge you not to define constants for TRUE and FALSE when the language doesn't provide them.
One of the nastiest bugs I ever had to track down was caused by someone defining these constants slightly differently than the way the language did. We were constantly surprised when !$is_bad, FALSE == $is_bad, and TRUE != $is_bad did not give the same answers.
My favorite readability move for code like this would be to rename the methods (maybe is_done) to work better in conditionals.
In your example, I have a bigger problem understanding why foo returning a true value means that we are not done. If, on the other hand, the method were named is_foo_running it would be easier to understand.
Although I have fought the no magic literals fight for years, true and false are not where I prefer to fight.
In reply to Re^2: Burned by precedence rules
by gwadej
in thread Burned by precedence rules
by vrk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |