On Fri, 29 Mar 2019 at 12:33, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>
> > | But down the line, absolutely yes Modules need to become objects. They
> > | would be as-if a giant struct full of data objects and function objects.
> > | They would be attached, and detached, exactly as any other object under
> > | this proposal. This would effectively implement shared libraries into C++.
> > |
> > | We then can redefine C++ programs to be a graph of binary Modules to be
> > | bootstrapped by a Modules loader. So your .exe program might be a few
> > | Kb, and it would simply map into memory all the binary Modules its
> > | manifest specifies from the system binary Modules database.
> >
> > What problems would such a proposal attempt to solve?
>
> The answer is "too many to usefully list". But I can give you my
> personal top three, for brevity and clarity.
>
>
>
> 1. It would solve the shared library problem for C and C++, without
> using broken proprietary shared libraries to do it.

*snip snap*

I don't follow this explanation at all. Earlier you said that a
program maps into memory some binary Modules.
Binary modules are object files. Mapping object files into memory is
exactly what my dynloader does today.

If you want to create some cloudy repository that "everybody" uses for
their builds, you can do it with shared libraries.
Many people already do. I don't see what "Modules need to become
objects" has to do with any of that. If you expect
programs to reach into a cloudy repository to magically update their
"binary modules" somehow differently from
updating their shared libraries, I don't see why we should expect that
to happen any more than it happens with
shared libraries.

Would you like to try that explanation again?