Either I'm not back or I never left. This place is toxic and I'm sorry I looked. I just wanted to put the code where I could find it again later. You guys don't even know what you are looking at.
Like the other guy, you miss the point. On any given day I may fabricate a decision tree consisting of one wacky question after another. Does the key FOO exist? If so, is it defined? If so, is its value not less than 42? If so, is the value of key BAR some true value? After passing all these checks I take an action. Then I decide to look for when FOO exists but is undefined and when BAR not exists. These trees sometimes grow in complexity over time and must be refactored.
The refactoring I show here consists of pulling all the conditionals out of the tree itself and setting explicit boolean flags. Then there are exactly 2^N outcomes possible, ever; and when the tree itself is written out it's easy to verify by eye that every case is exhausted.
The specific details of this one application of the approach are utterly without importance.
In reply to Re^2: Case Exhaustion Tree
by Xiong
in thread Case Exhaustion Tree
by Xiong
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |