Closed jaredoconnell closed 6 months ago
@jaredoconnell how should these behave when the two are not of the same type? We have some limited type conversion, for example from string to int, these rules can be applied in this case too, but we need to decide if we want that (see JavaScript type hell). We should also decide what to do if a certain value is not present (e.g. the one side is an object property that is not set.
@janosdebugs The least error prone way that takes advantage of the typing system I can think of would be to strictly enforce types, and have functions to_string, to_int, to_float, to_bool, etc. for when you want to compare unlike types.
What do you think of this method?
@jaredoconnell Isn't this closed with #23 ?
Yes, this is out of sync with JIRA.
Please describe what you would like to see in this project
Binary comparison operators should be added to the expression language. This will allow comparing values to create a boolean result. Binary comparison operators include:
>
<
>=
<=
==
!=
It may also make sense to add the not operator, which can likely be implemented as
!
This will be implemented as a new grammar rule that can be used in the root of an expression, and therefore anywhere where a sub-expression is explicitly or implicitly allowed.
Typing
Mismatched types will cause a type error. Due to all inputs being strongly typed, the only way for a type to change is for the plugin's schema to change. In that scenario, the workflow should fail until the workflow maintainer fixes the typing so that it matches on each side.
Please describe your use case
The main use case for this will be for conditional execution, so that the values being used to determine whether to execute the sub-workflow do not need to be boolean, but can instead be something compared to create a boolean.
This will also be useful for creating boolean results for step inputs, and workflow output.