Interface Finishing
- All Known Implementing Classes:
ArgumentSection, ReturnSection, SecFilter, SecFlatMap, SecLoop, SecMap, SecSwitch
public interface Finishing
CodeSections implementing this interface need to be 'finished' by convention. When this method is not called
when moving on to another statement, negative side-effects will always occur if this same
statement is being walked on again.
Examples of this are cache clearing, iterator clearing or result clearing in respectively sections like SecLoop, SecSwitch and SecMap.
Examples of this are cache clearing, iterator clearing or result clearing in respectively sections like SecLoop, SecSwitch and SecMap.
ArgumentSection implements this interface by default, because of their intrinsic nature of needing
a finishing method like this.- See Also:
-
Method Summary
Modifier and TypeMethodDescriptionvoidfinish()By convention, this method should be fired in one of the following occasions: The execution of the section is completely done and the (actual) next element is referenced to be walked on. This method is completely stopped by any means whatsoever. An example of this second occasion isEffContinuecontinuing over multiple loops.
-
Method Details
-
finish
void finish()By convention, this method should be fired in one of the following occasions:- The execution of the section is completely done and the (actual) next element is referenced to be walked on.
- This method is completely stopped by any means whatsoever.
EffContinuecontinuing over multiple loops. If that effect continues 3 loops in one go, this means that the 2 most inner-loops need to be completely reset, since they have the possibility to be looped over again. EffContinue therefore calls this method on those loops.
Another example isEffExit, which finishes every section that implements this interface, because of the same reasons specified above.- See Also:
-