Indeed. Best practices are trending towards making internal Apis public. But very very clearly making it clear "assume these get breaking changes every single release. "
On Tuesday, February 18, 2014, Niklas Hambüchen <mail@nh2.me> wrote:
On 18/02/14 12:57, Richard Cobbe wrote:
> And I'm not sure that I get many of the benefits of thinking about API
> boundaries, because I have to expose modules from the library if I want to
> write unit tests for them, even if they're not really part of the library's
> public interface.
Exactly that has bothered me for long.
If I want to make a proper cabal package with tests for internal API, I
have to expose the internal API (otherwise we get double building).
In general, I always recommend exposing all the code in .Internal
modules - I often run into problems with packages that don't do this.
Yet, the whole re-exporting overhead introduced by this is cumbersome,
and it doesn't make haddocks nicer either (e.g. when you come to a page
that is full of re-exports). I hope haddock will find a way to make this
nicer.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe