The Bitmap algebra provides some basic support for loading bitmaps but it is limited in the following ways:
It doesn't represent that loading a bitmap can fail for various reasons (file not found, incorrect format, etc.)
It loads bitmaps as a Picture (strictly speaking, it is loaded as the F in the algebra but in the current implementation this basically means Picture). This means we don't have a separate type representing bitmaps, which is a problem because bitmaps are distinct from the vector graphics model of the rest of Doodle and we can do interesting operations on them that don't make sense on vector images and vice versa.
What it should do instead:
the Bitmap algebra should be parameterized by at least one type, the type of bitmaps, and possibly by an effect type. I don't think we've abstracted over effect types elsewhere in Doodle so the effect type can be ignored if it adds too much complexity.
change the Bitmap algebra so that the main method reflects the possibility of failure (e.g. returns an IO, Either, or a Try. Probably an Either is better as it doesn't fix the error to be an Exception, and so works across different backends with different error handling strategies. Could abstract over error handling with the MonadError type class but I'm not convinced it's warranted.) Probably returning an IO is best as that is used in other parts of Doodle.
add some utilities to Bitmap to load a bitmap when you don't care about errors.
backends should implement ToPicture to convert a particular bitmap type into the backend specific Picture type.
where Specifier is the type of information that we used to specify where to find a bitmap (e.g. File on the JVM, String on the browser) and Bitmap is the type of the resulting bitmap (BufferedImage on the JVM.) Backend specific implementations could provide their own utility methods that augment the above.
Here are some links to relevant backend information:
The
Bitmapalgebra provides some basic support for loading bitmaps but it is limited in the following ways:Picture(strictly speaking, it is loaded as theFin the algebra but in the current implementation this basically meansPicture). This means we don't have a separate type representing bitmaps, which is a problem because bitmaps are distinct from the vector graphics model of the rest of Doodle and we can do interesting operations on them that don't make sense on vector images and vice versa.What it should do instead:
Bitmapalgebra should be parameterized by at least one type, the type of bitmaps, and possibly by an effect type. I don't think we've abstracted over effect types elsewhere in Doodle so the effect type can be ignored if it adds too much complexity.Bitmapalgebra so that the main method reflects the possibility of failure (e.g. returns anIO,Either, or aTry.Probably anProbably returning anEitheris better as it doesn't fix the error to be anException, and so works across different backends with different error handling strategies. Could abstract over error handling with theMonadErrortype class but I'm not convinced it's warranted.)IOis best as that is used in other parts of Doodle.Bitmapto load a bitmap when you don't care about errors.ToPictureto convert a particular bitmap type into the backend specificPicturetype.Concretely, we're looking at an interface like
where
Specifieris the type of information that we used to specify where to find a bitmap (e.g.Fileon the JVM,Stringon the browser) andBitmapis the type of the resulting bitmap (BufferedImageon the JVM.) Backend specific implementations could provide their own utility methods that augment the above.Here are some links to relevant backend information: