WIP: Case Insensitive Objects #38

Draft

modulatingforce wants to merge 0 commits from case-insensitive-objects into master

modulatingforce commented

2024-03-22 08:57:06 -04:00

Owner

In various area of code, I'm constantly having to remember to add .to_lowercase() because there's a known implied equality with those types. For example BotModule(name1) and BotModule(name2) are exactly the same if name1 = "Hello" and name2 = "hello"

Better would be to implement PartialEq and Eq traits for basic objects

Below is an example that seems to work in a different branch at the moment for BotModule

// #[derive(Debug, PartialEq, Eq, Hash, Clone)]
#[derive(Debug, Hash, Clone)]
pub enum ModType {
    BotModule(String),
}

impl PartialEq for ModType {
    fn eq(&self, other: &Self) -> bool {
        let BotModule(name1) = self.clone();
        let BotModule(name2) = other.clone();
        name1.to_lowercase() == name2.to_lowercase()
    }
}
impl Eq for ModType {}

Plan of Action

Review Rudimentary types (enum / structs) that derive PartialEq and Eq AND involve a String used to evaluate equality
- If Many, optionally Prioritize those that would benefit from case insensitive
- implement PartialEq and Eq for the types identified to change
May want to consider adding a new type Chatter(String)
- This will add more meaning to comparisons involving that string name
- This may require refactoring in structure such as HashMap that is currently just using String but known to be chatter names
- this new type should also involve the new implementations of PartialEq and Eq
Correct areas where we manually added to_lowercase()
Unit tests that tests for case insensitivity

Not a HIGH priority , but doing this will help remove the weight of needing to consider case sensitive names when code involves comparing for equality with these types (including in HashMap related methods)

Fun to learn : more coding with traits . Adding this to Rust Learning
Low Difficulty : Can likely be delegated to others

In various area of code, I'm constantly having to remember to add `.to_lowercase()` because there's a known implied equality with those types. For example `BotModule(name1)` and `BotModule(name2)` are exactly the same if name1 = "Hello" and name2 = "hello" Better would be to implement PartialEq and Eq traits for basic objects Below is an example that seems to work in a different branch at the moment for `BotModule` ```rust // #[derive(Debug, PartialEq, Eq, Hash, Clone)] #[derive(Debug, Hash, Clone)] pub enum ModType { BotModule(String), } impl PartialEq for ModType { fn eq(&self, other: &Self) -> bool { let BotModule(name1) = self.clone(); let BotModule(name2) = other.clone(); name1.to_lowercase() == name2.to_lowercase() } } impl Eq for ModType {} ``` --- # Plan of Action - [ ] Review Rudimentary types (enum / structs) that derive PartialEq and Eq AND involve a String used to evaluate equality - [ ] If Many, optionally Prioritize those that would benefit from case insensitive - [ ] implement PartialEq and Eq for the types identified to change - [ ] May want to consider adding a new type `Chatter(String)` - This will add more meaning to comparisons involving that string name - This *may* require refactoring in structure such as HashMap that is currently just using String but known to be chatter names - this new type should also involve the new implementations of PartialEq and Eq - [ ] Correct areas where we manually added `to_lowercase()` - [ ] Unit tests that tests for case insensitivity --- Not a HIGH priority , but doing this will help remove the weight of needing to consider case sensitive names when code involves comparing for equality with these types (including in HashMap related methods) - Fun to learn : more coding with traits . Adding this to Rust Learning - Low Difficulty : Can likely be delegated to others

WIP: Case Insensitive Objects #38

Plan of Action

Checkout