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

Command queries can be zero-arg testing methods #1207

Merged
merged 7 commits into from
Dec 16, 2023

Conversation

blairmcg
Copy link
Contributor

Many command queries do nothing other than set the enablement of the command, in which case the code is simpler and smaller if a command query method can be a simple testing method that takes no arguments and returns true if the command is to be enabled, or false if disabled.

This seems to apply to the majority of cases visited so far, and in quite a few cases allows for the use of existing testing methods to be used, reducing the proliferation of individual query methods specific to individual commands or related groups of commands.

Also perform some validation of the query annotations, since it is easy to make a small mistake, such as mispelling a selector, and end up breaking the command handling in the development tools. As the command queries are often called repeatedly as a background/idle task to revalidate the UI state (e.g. for toolbar buttons), this can cause repetitive errors that are at best annoying, and at worst terminal.

Replace old #queryCommand: methods in MoenTreeView, Card containers, collection presenters and workspace classes.

All the C++ prims follow a style that conditional forward jumps are not
taken except in the error case. This is because the default prediction
for a forward jump is that it is not taken.
Many command queries do nothing other than set the enablement of the
command, in which case the code is simpler and smaller if a command query
method can be a simple testing method that takes no arguments and returns
true if the command is to be enabled, or false if disabled.

This seems to apply to the majority of cases visited so far, and in quite
a few cases allows for the use of existing testing methods to be used,
reducing the proliferation of individual query methods specific to
individual commands or related groups of commands.

Also perform some validation of the query annotations, since it is easy to
make a small mistake, such as mispelling a selector, and end up breaking
the command handling in the development tools. As the command queries are
often called repeatedly as a background/idle task to revalidate the UI
state (e.g. for toolbar buttons), this can cause repetitive errors that
are at best annoying, and at worst terminal.
@blairmcg blairmcg merged commit cf14f5d into master Dec 16, 2023
2 checks passed
@blairmcg blairmcg deleted the blairmcg/querycommand4 branch December 16, 2023 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant