Consider:
let output: Vec<u8> = sha3::SHA3_256::new().hash(data);
The pattern of ::new().hash(..), where .hash(..) is a method, is a code smell since should really be a static function ::hash(..). The reason why it's like that is because the HashFactory requires the Hash trait to be dyn-compatible, and I was not able to get the factory to work with a static ::hash(..).
The task for this ticket is to play some more with whether it's possible to get the HashFactory to chain properly to a ::hash(..). If not, @npajkovsky suggested that we could cheat and simply have the Hash trait have both versions:
trait Hash {
fn hash(data: &[u8]) -> Vec<u8> {
Self::new().hash_method(data)
};
fn hash_method(self, data: &[u8]) -> Vec<u8>;
}
and then we continue to use the .hash_method(data) version within the HashFactory, but we can simplify the sample code in the crate docs to use the cleaner SHA256::hash(data) version.
Note: I'm using Hash as an example, but this smelly pattern exists across other traits as well. This ticket should clean up all similar patterns.
Consider:
The pattern of
::new().hash(..), where.hash(..)is a method, is a code smell since should really be a static function::hash(..). The reason why it's like that is because the HashFactory requires the Hash trait to be dyn-compatible, and I was not able to get the factory to work with a static::hash(..).The task for this ticket is to play some more with whether it's possible to get the HashFactory to chain properly to a
::hash(..). If not, @npajkovsky suggested that we could cheat and simply have the Hash trait have both versions:and then we continue to use the
.hash_method(data)version within the HashFactory, but we can simplify the sample code in the crate docs to use the cleanerSHA256::hash(data)version.Note: I'm using Hash as an example, but this smelly pattern exists across other traits as well. This ticket should clean up all similar patterns.