aeson and dlist in HP 2013.4.0.0

[Gregory Collins]

On Mon, Nov 18, 2013 at 5:40 PM, Peter Simons <simons at cryp.to> wrote:

> ...but I never had any trouble because
> a library exposed a type that I didn't need access to.
>

I've definitely had the experience of pattern matching on somebody's
constructor and then having my code break when a new record field was
added. The convention I use, and which I have seen others use, is that
datatypes are exported abstractly in "public" APIs but are also
(optionally) exported from an ".Internal" module. The "contract" you give
to API users about what kinds of changes should be breaking can then be a
little stronger in the public API. Consumers of modules marked "internal"
deserve what they get :)

Other concrete examples where this has helped me as a library author in the
past: In the snap-core web programming package, I have redefined the "Snap"
monad half a dozen times but consumers of the public library API have to my
recollection never been affected by these changes. This would not be
possible without the datatype abstraction.

As others have posted, keeping datatypes abstract also lets you maintain
invariants that unfettered access to the datatype constructors might allow
you to violate. For dozens of reasons it's a software engineering "best
practice".

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131118/6bcc8d00/attachment-0001.html>