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.
ArgumentSection implements this interface by default, because of their intrinsic nature of needing a finishing method like this.
See Also:
  • Method Summary

    Modifier and Type
    Method
    Description
    void
    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 is EffContinue continuing over multiple loops.
  • Method Details

    • finish

      void finish()
      By convention, this method should be fired in one of the following occasions:
      1. The execution of the section is completely done and the (actual) next element is referenced to be walked on.
      2. This method is completely stopped by any means whatsoever.
      An example of this second occasion is EffContinue continuing 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 is EffExit, which finishes every section that implements this interface, because of the same reasons specified above.
      See Also: