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.  <span></span>"<br><br>On Tuesday, February 18, 2014, Niklas Hambüchen <<a href="mailto:mail@nh2.me">mail@nh2.me</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18/02/14 12:57, Richard Cobbe wrote:<br>
> And I'm not sure that I get many of the benefits of thinking about API<br>
> boundaries, because I have to expose modules from the library if I want to<br>
> write unit tests for them, even if they're not really part of the library's<br>
> public interface.<br>
<br>
Exactly that has bothered me for long.<br>
<br>
If I want to make a proper cabal package with tests for internal API, I<br>
have to expose the internal API (otherwise we get double building).<br>
<br>
In general, I always recommend exposing all the code in .Internal<br>
modules - I often run into problems with packages that don't do this.<br>
<br>
Yet, the whole re-exporting overhead introduced by this is cumbersome,<br>
and it doesn't make haddocks nicer either (e.g. when you come to a page<br>
that is full of re-exports). I hope haddock will find a way to make this<br>
nicer.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Haskell-Cafe@haskell.org')">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote>