[Haskell-cafe] Practise of hiding contsructors and serialization

[Alexander Dunlap]

On Sun, Feb 22, 2009 at 5:23 PM, Marc Weber <marco-oweber at gmx.de> wrote:
>>    I usually use Data.Binary for serialization.
> Sure. But you can't derive Data.Binary easily for NominalDiffTime.
> That's the point. You can only do so by using toReal or by adding
> data MyOwnPico = MyOwnPico only to create serialization instances.
> I don't like this kind of code duplication..
>
> Marc

One advantage of the current system is that is preserves data
abstraction. For example, right now NominalDiffTime is declared

> newtype NominalDiffTime = MkNominalDiffTime Pico

so it would be possible for GHC or another automated tool to derive an
instance of Read, Show, Binary, whatever for it. However, what if, in
the future, the maintainer of the Time library wanted to change this
to

> newtype NominalDiffTime = MkNominalDiffTime Double

? Now your derived instance wouldn't be the same, so your serialized
data would not be compatible even between the same version of your
library even if the version of your library stayed the same because
the time library version had same.

Even worse, what if the Time library maintainer changed it to

> newtype NominalDiffTime = MkNominalDiffTime (Int -> Pico)

? Now you can't make a derived instance at all!

There's no really good reason why they would make these changes; it
seems reasonable that the Time library will stay in much the same form
for the forseeable future. However, the whole point of abstract
datatypes is that the maintainer can change the internals without
disrupting dependent packages, as long as the accessor functions has
the same semantics. In order for this to work, you can't have any
external code - even derived instances - relying on the internal
structure of abstract datatypes.

Alex