[darcs-devel] [patch1880] decouple RepoPatchV3 impl from NamedPrim

Ben Franksen bugs at darcs.net
Wed Aug 28 08:19:55 UTC 2019


Ben Franksen <ben.franksen at online.de> added the comment:

> patch 587d15fd349e13c83f49e70e7e004f03d4218463
> Author: Ganesh Sittampalam <ganesh at earth.li>
> Date:   Wed Aug 28 00:01:56 BST 2019
>   * Make D.P.V3.Core independent of NamedPrim/PrimPatchId

I am not yet convinced hiding of the Core.RepoPatchV3 constructors and
using a pattern synonym is worth the overhead here. We just uncovered
one example where we legitimately want to construct a Core.RepoPatchV3
from a named prim outside of the Core module, forcing us to export an
"unsafe" constructor function mkPrim, circumventing the abstraction
barrier. How is this any better than exporting the Prim constructor in
the first place?

For me, the "official" API has always been Darcs.Patch.Vx; anything
under that are implementation details, not to be accessed from outside.
Such a convention is IMO enough to ensure that invariants aren't
violated, and this is how we have always handled things for V1 and V2.
Has that ever been a problem in practice? Note that exposing Internal
modules (with appropriate warnings attached) is nowadays common practice
even for whole packages.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1880>
__________________________________


More information about the darcs-devel mailing list