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
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
On 18/02/14 12:57, Richard Cobbe wrote: 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 javascript:; http://www.haskell.org/mailman/listinfo/haskell-cafe