Hi, Am Donnerstag, den 26.02.2015, 20:50 +0100 schrieb Bardur Arantsson:
Having actually worked with code using this approach to versioning, I think I can safely say that it is absolute hell in practice -- way worse than sprinkling a few CPP directives here and there.
Interesting, and good to hear about that!
Granted, in my particular case data structures were also versioned thusly, and so you'd end up with reams of boilerplate (but only sometimes boilerplate!) Bool1<->Bool2 conversion code.
The way I imagine it to work, this would happen here, as the actual data type will always be the one from the current system’s base.
Similar problems would ensue if semantics of Foo1.frobnicate() and Foo2.frobnicate() were subtly different, but you'd happened to call the wrong one. Not to mention all the namespace pollution if you need to access both Foo1 and Foo2 in the same module.
Well, that should not ever need happen (comparable to how today, you never access base-4.6:Foo and base-4.7:Foo in the same package – I hope).
There's also the mental overhead of having to be aware of all the Foo1, Foo2, ... modules and the differences between them. (There's probably a lot more pain that I've just repressed, but that's just off the top of my head.)
The proper solution to this problem (as with so many things) is another layer of indirection, namely a proper way to separate API and implementation. (Aka "Backpack" or similar.)
But that is precisely what frozen-base is trying to provide – just APIs, no implementations. Note that it should merely re-export stuff from base (or maybe base-compat or similar), and simply guarantee that the set of exported functions of one particular module does not change any more. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org