#359: Constraints on state objects

In a
comment  on  Issue #168 , Jim made this suggestion:

For many of the tools that I have seen that include flows or traversals, when explaining a flow or graph traversal state, they specify the value of an _expression_ as a literal value  (expressible in this current design), or as a constraint on the value (currently not not expressible). Such as
{
  "i":  "i < 5",
  "j":  "j >= 10 && j < 100",
  "p":  "p != NULL ",
  "r":  "r == NULL",
  "s":  "strlen(s)
> 100",
  "t":  "buffer t is not NULL terminated"
}
This state constraint information that many tools report, could incorporate this without changing the schema by describing that a  magic string value such as "{expr}" is used to represent a constraint  _expression_. If "{expr}" exists in the value then it is a constraint (the value may substitute the actual _expression_ for {expr}.  If "{expr}" does not exist in the value then this is an equality constraint equivalent to "{expr} == VALUE" where VALUE is the value of the JSON property.
The above constraints would then become a state object of
{
  "i":  "{expr} < 5",
  "j":  "{expr} >= 10 && {expr} < 100",
  "p":  "{expr} != NULL ",
  "r":  "NULL",
  "s":  "strlen({expr})
> 100",
  "t":  "buffer {expr} is not NULL terminated"
}
For viewer just displaying the values above would probably be deciphered with the correct meaning by most developers, and advanced viewers could do more to indicate a general constraint  instead of just equality.

This is a nice design enhancement and it’s a non-breaking change with only one little  bit of magic  to explain, and I have the time, so I will incorporate it. I filed  Issue #359 , “Constraints in state objects.”

If anyone objects, please let us know.

Larry