Interesting article and discussion about Python's standard library

[H. S. Teoh]

On Tue, May 21, 2019 at 12:29:55PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 5/21/19 11:15 AM, David Gileadi wrote:
> > On 5/21/19 2:14 AM, Atila Neves wrote:
> > > For example, the libstd doesn't even have support for random
> > > number generation. There's a rand crate, which is now on 6th major
> > > breaking version. That's perfectly fine, because multiple versions
> > > can coexist in one program, and every user can upgrade (or not) at
> > > their own pace. And the crate was able to refine its interface six
> > > times, instead of being stuck with the first try forever.
> > 
> > Multiple coexisting versions is an interesting way of solving
> > dependency hell.
> 
> In terms of multiple simultaneously *installed* versions, I consider
> it an absolutely essential feature of any *good* package manager (This
> is a big part of why I hate most system-level Linux package managers,
> including the one on my own machine). But the idea of multiple
> versions *within one program* is indeed interesting.
> 
> Doesn't strike me as something you'd want to frequently take advantage
> of, but having it there as a viable workaround for when problems do
> arise could certainly be quite nice.

This is a very interesting idea indeed.  Goes along well with Andrei's
recent idea of addition vs. replacement.

And I think it's probably not hard to adopt in D (should we deem it a
good idea -- that's still arguable): all you need is for module
declarations to come with an attached version number, then include that
in the mangling. This automatically gives a unique identifier to symbols
in the module, so you could import multiple versions of the same module
and have the symbols resolve correctly. Just a minor change in module
declarations and in module name mangling.

Of course, how to handle imports that may have multiple satisfying
versions is another, stickier, question.


T

-- 
Meat: euphemism for dead animal. -- Flora