<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 29, 2019, at 6:48 AM, Ville Voutilainen &lt;<a href="mailto:ville.voutilainen@gmail.com" class="">ville.voutilainen@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Fri, 29 Mar 2019 at 12:33, Niall Douglas &lt;<a href="mailto:s_sourceforge@nedprod.com" class="">s_sourceforge@nedprod.com</a>&gt; wrote:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">| But down the line, absolutely yes Modules need to become objects. They<br class="">| would be as-if a giant struct full of data objects and function objects.<br class="">| They would be attached, and detached, exactly as any other object under<br class="">| this proposal. This would effectively implement shared libraries into C++.<br class="">|<br class="">| We then can redefine C++ programs to be a graph of binary Modules to be<br class="">| bootstrapped by a Modules loader. So your .exe program might be a few<br class="">| Kb, and it would simply map into memory all the binary Modules its<br class="">| manifest specifies from the system binary Modules database.<br class=""><br class="">What problems would such a proposal attempt to solve?<br class=""></blockquote><br class="">The answer is "too many to usefully list". But I can give you my<br class="">personal top three, for brevity and clarity.<br class=""><br class=""><br class=""><br class="">1. It would solve the shared library problem for C and C++, without<br class="">using broken proprietary shared libraries to do it.<br class=""></blockquote><br class="">*snip snap*<br class=""><br class="">I don't follow this explanation at all. Earlier you said that a<br class="">program maps into memory some binary Modules.<br class="">Binary modules are object files. Mapping object files into memory is<br class="">exactly what my dynloader does today.<br class=""><br class="">If you want to create some cloudy repository that "everybody" uses for<br class="">their builds, you can do it with shared libraries.<br class="">Many people already do. I don't see what "Modules need to become<br class="">objects" has to do with any of that. If you expect<br class="">programs to reach into a cloudy repository to magically update their<br class="">"binary modules" somehow differently from<br class="">updating their shared libraries, I don't see why we should expect that<br class="">to happen any more than it happens with<br class="">shared libraries.<br class=""><br class="">Would you like to try that explanation again?<br class=""></div></div></blockquote><br class=""></div><div>Not an explanation, but perhaps a hint at how modules could be tied to objects:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span><a href="http://wg21.link/N2074" class="">http://wg21.link/N2074</a>&nbsp; (“Plugins in C++”, 2006)</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Daveed</div><div><br class=""></div><br class=""></body></html>