I've been using it successfully for a lot of UI work. Even if you have a default handler function that gives a sane-ish default value for the context you'll be using it in (I.e "Loading..." in UI), I've found it helps keep interfaces sane even when you "forget" you actually care about the empty state.
On 2017-04-16 13:51, Saurabh Nanda wrote:
> Can we use the type-system (or anything else) to enforce the dev to at
> least _think_ about the blank state?
That is an interesting problem. But I'd say the solution depends highly
on your architecture. Tomas' suggestion to use NonEmpty could be one
solution, and one you could try to build upon to track more details in
the types. Alternatively, you could add a typeclass that just handles
the zero-element-case. That way your constraints remind the developer to
at least copy-paste a default implementation.
showItemTable :: (HasZeroItemPresentation (presenter item)) => presenter item -> [item] -> Table item
But maybe there's a much simpler solution: Create a datatype that stores
the normal presentation function, a zero-case presentation function, and
optionally a one-item presentation function. Now whenever someone
creates a new type of item, they need a new presentation adapter.
data TablePresenter item = TablePresenter { showZeroItems :: Widget; showItem :: item -> Widget; showSingleItem :: Maybe (item -> Widget) }
showItemTable :: TablePresenter item -> [item] -> Table item
This should offer safety and code reuse, and it should be easy to
integrate because you don't even have to start with types. Why be fancy
when the simple solutions work?
Cheers,
MarLinn
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
--