-
Notifications
You must be signed in to change notification settings - Fork 11
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
operator list is now coded in the frontend #646
operator list is now coded in the frontend #646
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I think we still need to simplify how the whole builder is managed in terms of state/context as this PR, even though it is quite small, was a little complex to read and follow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's maybe nitpicking but now that OperatorFunction
has been renamed OperatorOption
shouldn't we also rename the file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep true, I'll rename it
Hard agree. I think there is scope for quite a lot of simplification, the tricky thing is to find where to start. I did this one because it really touched things that I stumbled upon while working on the builder in Nov. I'm open for proposals, whether it's "small touch" refactors (like this, even though it touched a lot of lines of code) or more structural changes (as time allows). |
Continues #643, but with logic changes
The main difference is that the list of admissible AST Operators is no longer served from the backend. This was an early "by default" design decision, that did not age well.
Prerequisite for checkmarble/marble-backend#793