4 ms·
> There was one place where because of the type system, the implementation of the imaging library I was using would have led to an uncomfortable amount of code
by leshow 7y ago
> There was one place where because of the type system, the implementation of the imaging library I was using would have led to an uncomfortable amount of code repetition.
If you truly don't care about handling the different variants and want them all to execute the same code you could have just as easily done:
let w = image1.width();
let h = image1.height();
let mut diff = image::DynamicImage::new_rgb8(w, h);
If you don't care about image1.color() 's variants, why even have the match at all? I guess I don't understand why it 'rubbed you the wrong way'. You don't have to match anything if you don't want to, and if you do want to match variants, you have all the tools necessary to reduce duplication & only handle the variants you want to.
- deathanatos 7y agoI don't know if others do this, or if the Rust style guide particularly sanctions it, but in match sections that get overly verbose like that, I find it useful to do a local use statement to pull the enum variants into scope. E.g., use image::ColorType::*; match ... { RGB(_) => DynamicImage::new_rgb8(w, h), RGBA(_) => DynamicImage::new_rgb8a(w, h), } If you don't necessarily want the variants in the broader scope, it keeps them out of it, but within the local context of the match, the reader often will know what's being referred to. (And if they don't, the use statement will tell them.) Also, the author already has DynamicImage available in the scope (there's a use for it at the top) so the image:: prefix isn't needed in that section. There's also what looks like a manual expansion of try!() in run(), that could just be create_diff_image(...)? which would be less verbose.
- leshow 7y agoI prefer the constructors being in the scope personally because it feels similar to Haskell. I'm not sure why they decided to make them hidden.