Thoughts on versioning
Adam D Ruppe
destructionator at gmail.com
Wed Oct 27 14:22:16 UTC 2021
On Wednesday, 27 October 2021 at 13:57:50 UTC, Andrei
Alexandrescu wrote:
> It's interesting that both you and Sebastiaan mention an
> "inverted delta" of sorts whereby current std is redone to use
> std2.
Well, generally new functions end up being more fundamental than
old, so this is just naturally simpler.
In the case of the Windows functions, the Unicode functions can
take any string the ANSI functions can, which is not true vice
versa. So naturally, you'd be forced to write the less functional
one in terms of the more functional one.
In the case of various Phobos modules:
* Removing autodecoding in v2 makes it more general. You can
always write an autodecode function in terms of a plain function
- just do a wrapper that adds the decode adapter.
Doing it the other way happens to be possible here too, using a
byCodeUnit wrapper, but generally it is easier to add something
in a wrapper than remove something that was already added.
* Some people hate std.socket because it uses classes. Well, if
you build a std2.socket on top of it, those people will still be
angry. But std2.socket could be a struct api and then the
original std.socket class is built on top of it.
(in that case it would probably be a waste of time; just keeping
the original std.socket unmodified - it is already a fairly thin
layer on the underlying C functions anyway - and writing
std2.socket right on top of the underlying C functions too is
easy enough.)
* A generalization of std.socket: you can always build GC
functions on top of @nogc foundations (e.g. `string
toLower(string s) { return s.asLowerCase.array; } `). Not true
other way around.
* If you want to trim down an interface, again, you can define
std.v2 to be minimal then layer on stuff for compatibility on
top. Users who stick to std.v2, importing just it and not the old
one, they will not pay the cost of carrying these functions
around.
But if you defined std.v2 on top of std.v1, it is impossible to
remove functions. If a user imports std.v2, they automatically
drag all the std.v1 baggage along too, whether they like it or
not.
* Just as a matter of merge conflicts, making the bulk of your
edits on the forward moving version is a more natural way to work.
The con here is maintaining compatibility with the old one is a
bit harder since you're making edits and the old one might rely
on it. But.... worse case you just copy/paste when the divergence
is too much and lock in the old version letting the new one
evolve.
More information about the Digitalmars-d
mailing list