Branching
From dis-Emi-A
Contents |
Intro
The goal of branching is of course to provide proper branching without falling into the Evil If trap. For that we need to identify the several needs of branching.
- Switches
- the execution path branches to a specific set of code based on a condition -- from a need to have polymorphism/workflows
- Algorithmic branch
- the mathematical algorithm has a specific branch that needs to be implemented in the code (this is a type of guard)
- Mode of operation
- differing code needs to be executed based on the context of execution
- ???
Switches
The most common switch is one taking the form of the C switch. It has two major faults, one with the required "break" statement and fall-thurs (Which can be confusing, and often missed, yet sometimes desired) and the limitation to integer only types. Other languages have of course introduced switches that can handle more types.
Switches are used to compare a single variable against many options and then execute resulting code based whichever one matches. A default is often used, and sometimes executing more than one item is desired.
on mode
{
[ = "normal" ]
{
}
[ = "extra" ]
{
}
[ startsWith( "fancy" ) ]
{
}
[ otherwise ]
{
}
}
Algorithmic branch
As algorithmic branches are inherent to computational and mathematical algorithms, pertaining to data structures, encoding, and calcualtions, they cannot be pushed away. To keep as close to possible as the non-programming realm these should be left in a fairly understandable form, notable a guard condition (as would be expressed in mathematics).
[ search < key ]
{
searchOnLeft();
}
Since often exeution is required in the negative case as well, the rules can be chained with an otherwise clause.
[ i in 4..9 ]
{ ... }
[ otherwise ]
{ ... }
Though if you were to chain many items, even in the above case, it starts looking like a switch statement.
It is important to note than there is particular need that the branching/switch must evaluate to a specific value, rather than do execution -- additionally that execution results in the Evil If whereas evaluation does not.
a =
[ b < 5 ]
cos( c )
[ b < 10 ]
sin( c )
[ otherwise ]
0
;
Well, how does this chain really work? In assignment it is clear only one can be evaluated, but to be consistent there needs to be a way to distinguish.
Mode of operation
Branching on the mode of operation is used in cases where hooks are setup, or where special pre and post processing is required for a specific environment. Using if's for this purpose is wrong, that is what is known as the Evil If: it leads to code duplication, handling errors, maintenance hell, spaghettie code, etc.
Another solution is of course Aspect oriented programming, though that also leads to its own special kind of spaghetti code hell (there is no way upon inspeciton to determine what may happen in the particular code).
Perhaps they could be combined together however.
There are several distinct operations a hook could perform.
- Alter Input
- The input to the function could be altered by the hook
- Abort Operation
- The operation performed by the function can be aborted
- Pre-Trigger
- trigger an external event when the operation is attempted
- Post-Trigger
- trigger an external event when the operation is complete (possibly based on success status)
- Alter output
- The output from the function could be altered by the hook
