modulatingforce/forcebot_rs

Fork 0

WIP: Use `matches` macro #49

Closed

modulatingforce wants to merge 0 commits from use-matches into master

modulatingforce commented

2024-03-27 19:53:02 -04:00

Owner

In Logical Code areas where we're validating an enum for it's variant without really caring about the value, we should use the matches!() macro

https://doc.rust-lang.org/std/macro.matches.html

There's definitely areas where this is needed

I know for certain, for example, there's areas that validate Required Roles variants, but don't care about the value

In Logical Code areas where we're validating an `enum` for it's variant without really caring about the value, we should use the `matches!()` macro https://doc.rust-lang.org/std/macro.matches.html There's definitely areas where this is needed I know for certain, for example, there's areas that validate Required Roles variants, but don't care about the value

modulatingforce added this to the Forcebot Prototype 1.0 Push project 2024-03-27 19:53:03 -04:00

modulatingforce added the

Requirements > Drafting

labels 2024-03-27 19:54:18 -04:00

modulatingforce added

and removed

labels 2024-03-27 19:59:12 -04:00

modulatingforce commented

2024-03-28 16:11:43 -04:00

Author

Owner

For these conditions, I seem to have needed to use a for loop and match, like the below in for routines

        // [x] 2. Built in Logic will check these vectors, and return if Not Implemented

        // let mut unimplemented = routine_attr.iter()
        //     .filter(|x| {
        //         let inx = x;
        //         wip_attr.iter().filter(|y| matches!(y,i if i == inx)).next().is_none() 
        //         && implemented_attr.iter().filter(|y| matches!(y,i if i == inx)).next().is_none()
        //     }
        // );


        for given_routine in routine_attr {

            if !matches!(given_routine,RoutineAttr::DelayedStart)
            && !matches!(given_routine,RoutineAttr::ScheduledStart(_))
            && !matches!(given_routine,RoutineAttr::LoopDuration(_))
            && !matches!(given_routine,RoutineAttr::LoopInfinitely)
            && !matches!(given_routine,RoutineAttr::RunOnce)
            && !matches!(given_routine,RoutineAttr::MaxTimeThreshold(_))
            && !matches!(given_routine,RoutineAttr::MaxIterations(_))
            {
                botlog::trace(
                    "[ERROR][Routine Feature NOT IMPLEMENTED]",
                    Some("Routine > Validate_attr()".to_string()),
                    None,
                );

                Log::flush();

                return Err("NOT IMPLEMENTED".to_string());
            }

        };

I mean it would be nicer if I could fit everything in one line, but looking at the above seems relatively clean at a glance logically, so I think I prefer the match! uses similar to the above

Just to note, I'm not sure if this will work in every case. I discovered that my original matches logic involving filters on iterators and using match was not matching in the way I expected it (though my original expectations were incorrect) For these conditions, I seem to have needed to use a for loop and match, like the below in for routines ```rust // [x] 2. Built in Logic will check these vectors, and return if Not Implemented // let mut unimplemented = routine_attr.iter() // .filter(|x| { // let inx = x; // wip_attr.iter().filter(|y| matches!(y,i if i == inx)).next().is_none() // && implemented_attr.iter().filter(|y| matches!(y,i if i == inx)).next().is_none() // } // ); for given_routine in routine_attr { if !matches!(given_routine,RoutineAttr::DelayedStart) && !matches!(given_routine,RoutineAttr::ScheduledStart(_)) && !matches!(given_routine,RoutineAttr::LoopDuration(_)) && !matches!(given_routine,RoutineAttr::LoopInfinitely) && !matches!(given_routine,RoutineAttr::RunOnce) && !matches!(given_routine,RoutineAttr::MaxTimeThreshold(_)) && !matches!(given_routine,RoutineAttr::MaxIterations(_)) { botlog::trace( "[ERROR][Routine Feature NOT IMPLEMENTED]", Some("Routine > Validate_attr()".to_string()), None, ); Log::flush(); return Err("NOT IMPLEMENTED".to_string()); } }; ``` I mean it would be nicer if I could fit everything in one line, but looking at the above seems relatively clean at a glance logically, so I think I prefer the `match!` uses similar to the above

modulatingforce added the

Ownership

Individual Lead

label 2024-03-31 09:46:55 -04:00

modulatingforce self-assigned this 2024-03-31 09:47:15 -04:00

modulatingforce commented

2024-03-31 09:50:25 -04:00

Author

Owner

Really need to double check if this is required or not , and then flesh out the requirements more before considering delegating

LULE honestly thought this would be quick, hence the PR.

However, if this is something that needs more requirements fleshing out, I'll close this out to a New Issue

Really need to double check if this is required or not , and then flesh out the requirements more before considering delegating LULE honestly thought this would be quick, hence the PR. - [ ] However, if this is something that needs more requirements fleshing out, I'll close this out to a New Issue

modulatingforce added the due date 2024-04-06

2024-03-31 09:50:45 -04:00

modulatingforce added the

Status

Need More Info

label 2024-03-31 09:58:44 -04:00

modulatingforce added the

Kind/Enhancement

label 2024-03-31 10:01:08 -04:00

modulatingforce added

and removed

labels 2024-04-02 09:07:57 -04:00

modulatingforce commented

2024-04-02 09:08:15 -04:00

Author

Owner

Abandoning . Really low priority if an issue, and not really impacting if we enforce in existing code. I've been using this macro though for newer code

I think I wanted to demo this macro, but I have since discovered so many more macros and crates that are also worth showcasing

If we require any Showcasing , I think best path is to :

Start with an Issue, maybe about it being a Demonstration (a label maybe?)
If the demo requires a branch to play around and exercise, either create the PR & Branch live or some time before the demo/workshop

**Abandoning** . Really low priority if an issue, and not really impacting if we enforce in existing code. I've been using this macro though for newer code I _think_ I wanted to demo this macro, but I have since discovered so many more macros and crates that are also worth showcasing If we require any **Showcasing** , I think best path is to : 1. Start with an Issue, maybe about it being a `Demonstration` (a label maybe?) 2. If the demo requires a branch to play around and exercise, either create the PR & Branch _live or some time before_ the demo/workshop

modulatingforce closed this pull request

2024-04-02 09:08:15 -04:00

modulatingforce deleted branch use-matches

2024-04-02 09:09:21 -04:00