Currently the factory objects look like this:
pub enum HashFactory {
///
SHA224(sha2::SHA224),
///
SHA256(sha2::SHA256),
///
SHA384(sha2::SHA384),
///
SHA512(sha2::SHA512),
///
SHA3_224(sha3::SHA3_224),
///
SHA3_256(sha3::SHA3_256),
///
SHA3_384(sha3::SHA3_384),
///
SHA3_512(sha3::SHA3_512),
}
...
fn hash(self, data: &[u8]) -> Vec<u8> {
match self {
Self::SHA224(h) => h.hash(data),
Self::SHA256(h) => h.hash(data),
Self::SHA384(h) => h.hash(data),
Self::SHA512(h) => h.hash(data),
Self::SHA3_224(h) => h.hash(data),
Self::SHA3_256(h) => h.hash(data),
Self::SHA3_384(h) => h.hash(data),
Self::SHA3_512(h) => h.hash(data),
}
}
This code is highly repetitive and begging for a macro, maybe of the form:
impl_hash_factory!(SHA224, SHA256, SHA384, SHA512, SHA3_224, SHA3_256, SHA3_384, SHA3_512)
That said, I generally find macros for the sake of reducing the number of lines of code are not worth it because they make the code harder to read, harder to debug, and harder to test. So I think we should do the refactor of bouncycastle-factory to use macros, just to see what it looks like, and then decide if it is actually an improvement or not.
Currently the factory objects look like this:
This code is highly repetitive and begging for a macro, maybe of the form:
That said, I generally find macros for the sake of reducing the number of lines of code are not worth it because they make the code harder to read, harder to debug, and harder to test. So I think we should do the refactor of bouncycastle-factory to use macros, just to see what it looks like, and then decide if it is actually an improvement or not.