You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two conveniences that will be useful on writers:
methods using a DefaultFrame (depends on Abstract default frame #148) instead of requiring the user to pass a Frame
methods that return just the output type and discard the A value in the Picture (A is almost always Unit; discarding it is what draw does.)
These can both be implemented as syntax. (It's good to not have redundant methods on the type classes / algebras, though this is not consistently followed.)
(What's below is more speculative.)
There are a number of writers that don't require any input beyond the Picture and Frame (e.g. writing to an value, like Base64 or a BufferedImage). To ensure consistency for these kinds of writers we can define a subtype of Writer, let's say ValueWriter:
There are two conveniences that will be useful on writers:
DefaultFrame
(depends on Abstract default frame #148) instead of requiring the user to pass aFrame
A
value in thePicture
(A
is almost alwaysUnit
; discarding it is whatdraw
does.)These can both be implemented as syntax. (It's good to not have redundant methods on the type classes / algebras, though this is not consistently followed.)
(What's below is more speculative.)
There are a number of writers that don't require any input beyond the
Picture
andFrame
(e.g. writing to an value, likeBase64
or aBufferedImage
). To ensure consistency for these kinds of writers we can define a subtype ofWriter
, let's sayValueWriter
:Then we can define syntax on
ValueWriter
that all implementations will automatically have. Probably something likepicture.to[Out]
where the type variable
Out
is used to select theValueWriter
instance.The text was updated successfully, but these errors were encountered: