-
Notifications
You must be signed in to change notification settings - Fork 592
Add padding width #1672
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
base: main
Are you sure you want to change the base?
Add padding width #1672
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -33,6 +33,8 @@ | |
|
||
#[cfg(all(feature = "alloc", not(feature = "std"), not(test)))] | ||
use alloc::boxed::Box; | ||
#[cfg(feature = "alloc")] | ||
use alloc::sync::Arc; | ||
use core::fmt; | ||
use core::str::FromStr; | ||
#[cfg(feature = "std")] | ||
|
@@ -149,13 +151,71 @@ pub enum Numeric { | |
/// For formatting, it assumes UTC upon the absence of time zone offset. | ||
Timestamp, | ||
|
||
#[cfg(feature = "alloc")] | ||
/// An extension to carry the width of the padding. | ||
Padded { | ||
/// The numeric to be padded. | ||
numeric: Arc<Numeric>, | ||
/// The width of the padding. | ||
width: usize, | ||
}, | ||
|
||
/// Internal uses only. | ||
/// | ||
/// This item exists so that one can add additional internal-only formatting | ||
/// without breaking major compatibility (as enum variants cannot be selectively private). | ||
Internal(InternalNumeric), | ||
} | ||
|
||
#[cfg(feature = "alloc")] | ||
impl Numeric { | ||
/// Adds the with of the padding to the numeric | ||
/// | ||
/// Should be removed if the padding width is added to the `Pad` enum. | ||
pub fn with_padding(self, width: usize) -> Self { | ||
if width != 0 { | ||
// update padding | ||
match self { | ||
Numeric::Padded { numeric, .. } => Numeric::Padded { numeric, width }, | ||
numeric => Numeric::Padded { numeric: Arc::new(numeric), width }, | ||
} | ||
} else { | ||
// remove padding | ||
match self { | ||
Numeric::Padded { numeric, .. } => numeric.as_ref().clone(), | ||
numeric => numeric, | ||
} | ||
} | ||
} | ||
|
||
/// Gets the numeric and padding width from the numeric | ||
/// | ||
/// Should be removed if the padding width is added to the `Pad` enum. | ||
pub fn unwrap_padding(&self) -> (&Self, usize) { | ||
match self { | ||
Numeric::Padded { numeric, width } => (numeric.as_ref(), *width), | ||
numeric => (numeric, 0), | ||
} | ||
} | ||
} | ||
|
||
#[cfg(not(feature = "alloc"))] | ||
impl Numeric { | ||
/// Adds the with of the padding to the numeric | ||
/// | ||
/// Should be removed if the padding width is added to the `Pad` enum. | ||
pub fn with_padding(self, _width: usize) -> Self { | ||
self | ||
} | ||
|
||
/// Gets the numeric and padding width from the numeric | ||
/// | ||
/// Should be removed if the padding width is added to the `Pad` enum. | ||
pub fn unwrap_padding(&self) -> (&Self, usize) { | ||
(self, 0) | ||
} | ||
} | ||
Comment on lines
+202
to
+217
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is this useful? I don't think these should be part of the public API. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Becauase we don't add the padding width to the Pad enum and try to add it using dynamic memory allocation to the Numeric enum we have multiple cases to handle if we want to work with padding. Because the lib can also be used without dynamic memory allocation the code has to be deactivated in that cases. This is done by the "with_padding" and "unwrap_padding" functions. Because the Numeric enum is public this functions should also be public to help working with the padding. |
||
|
||
/// An opaque type representing numeric item types for internal uses only. | ||
#[derive(Clone, Eq, Hash, PartialEq)] | ||
pub struct InternalNumeric { | ||
|
@@ -555,3 +615,46 @@ impl FromStr for Month { | |
} | ||
} | ||
} | ||
|
||
#[cfg(test)] | ||
mod tests { | ||
use crate::format::*; | ||
|
||
#[test] | ||
#[cfg(feature = "alloc")] | ||
fn test_numeric_with_padding() { | ||
// No padding | ||
assert_eq!(Numeric::Year.with_padding(0), Numeric::Year); | ||
|
||
// Add padding | ||
assert_eq!( | ||
Numeric::Year.with_padding(5), | ||
Numeric::Padded { numeric: Arc::new(Numeric::Year), width: 5 } | ||
); | ||
|
||
// Update padding | ||
assert_eq!( | ||
Numeric::Year.with_padding(5).with_padding(10), | ||
Numeric::Padded { numeric: Arc::new(Numeric::Year), width: 10 } | ||
); | ||
|
||
// Remove padding | ||
assert_eq!(Numeric::Year.with_padding(5).with_padding(0), Numeric::Year); | ||
} | ||
|
||
#[test] | ||
#[cfg(not(feature = "alloc"))] | ||
fn test_numeric_with_padding_disabled() { | ||
// No padding | ||
assert_eq!(Numeric::Year.with_padding(0), Numeric::Year); | ||
|
||
// Add padding | ||
assert_eq!(Numeric::Year.with_padding(5), Numeric::Year); | ||
|
||
// Update padding | ||
assert_eq!(Numeric::Year.with_padding(5).with_padding(10), Numeric::Year); | ||
|
||
// Remove padding | ||
assert_eq!(Numeric::Year.with_padding(5).with_padding(0), Numeric::Year); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want your diff to have minimal changes to the structure of the code, or to isolate structural (but non-functional) changes in a separate commit. Is that feasible? The current iteration seems pretty hard to review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original code only had the oportunity to have exactly one or two padding signs. So there where special functions "write_one" and "write_two" to exactly do that. Because we now have a dynamic amount of padding signs it whould make the code more complex to have some kind of selection logic for "write_xxx" methods when we already had a method to write any amount of padding signs.