Hi all,
Thanks for more feedback.
I tend to not be afraid of the ".Internal" module that exposes stuff that
changes, with appropriate caveats. But it also seems like relatively
little effort to have a cleaner public "splitTree" interface in this case,
hopefully without extra overhead.
I propose to test simple use cases of a tuple and list version of splitTree
and check out the deforestation properties.
Milan, I know the three-tuple version looks weird. But since it's OK for
some of those three chunks to be empty I think most future implementations
would have an easy way to maintain compatibility, wouldn't they?
UNLESS, that is,y our new changes involve trees that would expose
*more*than three-way-splits at a time (4-way, 5-way, etc). Do they?
Cheers,
-Ryan
On Mon, Oct 7, 2013 at 12:51 PM, Edward Kmett
While it is PVP compliant, it would also tie the hands of the developers enough that I don't see many developers wanting to adopt it. Working across multiple packages means very painful changes to your build process if you don't use cabal install for everything. It is even rather painful if you do use cabal install for everything.
A slightly more palatable PVP compliant version which burns through version numbers much faster is to separate the two digits of the major version and use one for .Internal changes and one for changes to the majority of the public API. Then users who only use the public API can depend on the first digit. However, this has awkward aesthetics as your version numbers start skyrocketing.
I'm not a fan of either approach.
-Edward
On Mon, Oct 7, 2013 at 10:35 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Mon, 7 Oct 2013, Edward Kmett wrote:
A rule of thumb that has served me well w.r.t exposing internal modules
is to expose a Data.Foo.Internal but make it clear it is a very fragile interface. Even by going to far as to say this module does not follow the PVP and that they should expect breaking changes to come fast and often. Users should only safely depend on it with minor-version specific bounds then. This ameliorates the concerns about how it ties your hands as an implementor.
A PVP compliant solution would be to divide 'containers' into 'containers-internal' and 'containers'. The new package 'containers-internal' exposes internal data structures, but increases version numbers at a higher rate than 'containers'. The package 'containers' would only expose the public API and thus a more stable interface.