Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binary Comparison Operators #2

Closed
jaredoconnell opened this issue Mar 7, 2023 · 4 comments
Closed

Binary Comparison Operators #2

jaredoconnell opened this issue Mar 7, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@jaredoconnell
Copy link
Contributor

jaredoconnell commented Mar 7, 2023

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.

@jaredoconnell jaredoconnell added the enhancement New feature or request label Mar 7, 2023
@jaredoconnell jaredoconnell self-assigned this Mar 7, 2023
@ghost
Copy link

ghost commented Mar 7, 2023

@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.

@jaredoconnell
Copy link
Contributor Author

@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?

@dustinblack
Copy link
Member

@jaredoconnell Isn't this closed with #23 ?

@jaredoconnell
Copy link
Contributor Author

Yes, this is out of sync with JIRA.

@github-project-automation github-project-automation bot moved this from Backlog to Done in Arcaflow May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
No open projects
Archived in project
Development

No branches or pull requests

2 participants