<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>What seems most suspect to me is the relation of a Swift module to a build target. Do you mean we literally mate the concepts and provide IDE support, or is that more of a conceptual point?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I think the package manager's eventual goal of supporting multi-product packages covers most of what you want here (besides, maybe, the performance problems with dynamic linking).</div><div id="AppleMailSignature"><br>~Robert Widmann</div><div><br>2017/03/05 22:55、David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Apologies on creating yet another modulary thread in parallel, but I don’t believe I have seen the approach I’ve been mulling over considered. I have been contemplating submodules not from an access scoping perspective, but from a packaging one. In other words rather than defining the ability to have a module contain modules, have multiple peer-level modules contained a library or executable. A module would effectively be a build target, and applications/libraries are composed of modules.<div class=""><div class=""><br class=""></div><div class="">I’m not yet proposing any other features which would make this work conceptually differently than having one library per module today - I want to see if there is positive feedback around this first. </div><div class=""><br class=""></div><div class="">This approach has several advantages that I can think of:</div><div class="">1. Relatively simple model to explain</div><div class="">2. Additive proposal - if someone wishes to continue to make a framework or app with just a single module, the tools can work the same way they do today</div><div class="">3. Still encourages smaller modules, while today this would cause an explosion of included libraries</div><div class="">4. Smaller modules provide a tighter level of encapsulation, alleviating some of the pressure for access control levels between module-internal and private</div><div class="">5. Resolves existing startup performance issues of dynamic linking large numbers of libraries by allowing modules to be combined into fewer libraries.</div><div class="">6. Since modules are defined as build targets:</div><div class=""> 6.1 it is possible to model a filesystem-based grouping for modules using build tools</div><div class=""> 6.2 source in a module does not need any changes such as annotation to indicate which module it is part of</div><div class=""> 6.3 support isn’t modeled by the visual layout of an IDE, can be represented in a multi-target swift package manager file (SE-0146)</div><div class=""><br class=""></div><div class="">This approach also has two identified disadvantages in its current, simplistic form:</div><div class="">1. no inter-module access control yet proposed. This requires extra consideration with modules as a packaging concept, since modules would need to be bundled into the same binary unit</div><div class="">2. modules cannot have cyclic type dependencies (same as libraries today). My personal experience is that this leads to better code design and maintainability, but it can be more difficult when designing modules, or refactoring one module into many. </div><div class="">3. as an extension of the above, the extra constraints on making code into a module would limit the ability to use modules as a grouping/naming system for exposed API - dependencies would need to be structured for such a thing to work, which might require code changes</div><div class="">4. some submodule proposals may have allowed for a hierarchy of module names, e.g. Foundation and <a href="http://Foundation.Net" class="">Foundation.Net</a>. There is nothing yet in this proposal which would define how such a system would work.</div></div><div class="">5. I do not have enough knowledge of the functioning of the Swift compiler and build tools to know the impact of this approach.</div><div class="">6. Technically this does not preclude submodules as well, although I would suspect having both concepts would mean too much complexity.</div><div class=""><br class=""></div><div class="">Comments?</div><div class=""><br class=""></div><div class="">-DW</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>