Add increment_severity() and decrement_severity() methods for Level and LevelFilter
#692
Conversation
src/lib.rs
Outdated
| /// assert_eq!(Level::Debug, level.up()); | ||
| /// assert_eq!(Level::Trace, level.up().up()); | ||
| /// assert_eq!(Level::Trace, level.up().up().up()); // max level |
There was a problem hiding this comment.
Maybe these should be fn add(&self, n: u8) -> Self / subtract? To allow jumping multiple levels without repeated calls.
There was a problem hiding this comment.
That'd be fine with me, but I've gotten the impression that exposing any kind of numerically-oriented API is unwanted, aside from being able to cast as <integer>. I just hate having to do an unsafe transmute if I want to change the level.
There was a problem hiding this comment.
Fair point. For what it's worth, something like this would be much better than actually transmute:
fn log_level(a: u32) -> Level {
match a {
1 => Level::Error,
2 => Level::Warn,
3 => Level::Info,
4 => Level::Debug,
5 => Level::Trace,
_ => panic!("unknown log level"),
}
}...but I get the reasoning to want something builtin.
There was a problem hiding this comment.
Funny enough, that's basically what I had in my own code before just going, fuck it, I'll transmute :)
But that's so much boilerplate for what should be something trivial!
|
Thanks for the PR @nebkor! Functionality wise this looks good to me. Naming wise, I think we should aim for something a bit more descriptive than |
| /// assert_eq!(Level::Trace, level.increment_severity().increment_severity()); | ||
| /// assert_eq!(Level::Trace, level.increment_severity().increment_severity().increment_severity()); // max level | ||
| /// ``` | ||
| pub fn increment_severity(&self) -> Self { |
There was a problem hiding this comment.
@KodrAus love the suggestion!
|
The examples point this out already, but just leaving a note here for anyone who finds their way back to this PR; the semantics of increment and decrement here are the same as syslog's. To increment the severity means to reduce it. To decrement the severity means to increase it. I think this is still the correct behavior because it means we don't reverse the order of iteration, or comparison, when incrementing and decrementing. |
@KodrAus could you provide a ref here? I don't find how syslog defines this rule. Also, perhaps we can change the PR title to align with the final accepted method names. |
up() and down() methods for Level and LevelFilterincrement_severity() and decrement_severity() methods for Level and LevelFilter
This is an alternative to exposing
usizeconstructors for these enums, that still allows fluent manipulation of the level, a la,