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

Isn't Enum better for WorkingKeys? #12

Open
omid opened this issue Mar 6, 2023 · 2 comments
Open

Isn't Enum better for WorkingKeys? #12

omid opened this issue Mar 6, 2023 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed todo

Comments

@omid
Copy link

omid commented Mar 6, 2023

It looks like WorkingKeys can be an Enum.
And so state.working_keys can be a simple array, or if you insist for the uniqueness, it can be a BTreeSet.

@pouriya
Copy link
Owner

pouriya commented Mar 6, 2023

We need to iterate on them in here so that's why we make them iterable here.
We also need to make some keys active/inactive (if any error occurs) here and that's why I preferred struct.
Do you have any suggestion?

@pouriya pouriya added the enhancement New feature or request label Mar 6, 2023
@omid
Copy link
Author

omid commented Mar 6, 2023

IMHO, WorkingKeys.to_info_list should actually return an array of a struct like this:

struct Key {
  shortcut: String,
  description: String,
  key: KeyEnum,
}

and then KeyEnum can be:

enum KeyEnum {
  Q,
  Up,
  Down,
...
}

I'm not so familiar with the source code.
But if you need to keep the enabled ones somewhere, maybe a Vec<&Key> can do the job.

PS: then it'll be better to impl PartialEq manually for Key.

@pouriya pouriya added help wanted Extra attention is needed todo labels Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed todo
Projects
None yet
Development

No branches or pull requests

2 participants