Commits on Jan 7, 2022

1. handle variable evaluation in one location …

   Module variable evaluation was spread out over 3 locations, which led to
   a skew in what value could be seen within a module, and what value could
   be seen within a variable's own validation scope.
   
   First, the graph transformer would create a fake input expression on the
   fly for variables with no input, and load it with the default value.
   This caused trouble during actual evaluation where the input expression
   would be mapped to the wrong source location, and made it difficult to
   determine if an input value was really assigned or not.
   
   The variables nodes would then evaluate the expression, but not be able
   to handle defaults, because there always appeared to be an input
   expression set for the variable. Because defaults could not be handled,
   the wrong value could be passed into the validation expressions for the
   variable.
   
   GetInputVariable from the evaluator would check again for defaults, but
   was usually fooled by the fake expression value. Even when it could
   assign a default, as in the case of `nullable=false` with a null input,
   it was already too late for the variable validation block to handle it.
   
   We can unify all evaluation handling into the nodeModuleVaraible exec
   node. This way the context is always loaded with the correct final value
   of the variable, so GetInputVariable is only concerned with fetching
   that value to evaluate references to it, and the graph transformer is
   taken out of the picture entirely.

   

   jbardin committed Jan 7, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for 87eaf67
   • Browse repository at this point

   Copy the full SHA

   87eaf67 View commit details

   Browse the repository at this point in the history