[swift-evolution] A Modest (multi-module) Proposal

[Robert Widmann]

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?

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).

~Robert Widmann

2017/03/05 22:55、David Waite via swift-evolution <swift-evolution at swift.org> のメッセージ:

> 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.
> 
> 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. 
> 
> This approach has several advantages that I can think of:
> 1. Relatively simple model to explain
> 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
> 3. Still encourages smaller modules, while today this would cause an explosion of included libraries
> 4. Smaller modules provide a tighter level of encapsulation, alleviating some of the pressure for access control levels between module-internal and private
> 5. Resolves existing startup performance issues of dynamic linking large numbers of libraries by allowing modules to be combined into fewer libraries.
> 6. Since modules are defined as build targets:
>    6.1 it is possible to model a filesystem-based grouping for modules using build tools
>    6.2 source in a module does not need any changes such as annotation to indicate which module it is part of
>    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)
> 
> This approach also has two identified disadvantages in its current, simplistic form:
> 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
> 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. 
> 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
> 4. some submodule proposals may have allowed for a hierarchy of module names, e.g. Foundation and Foundation.Net. There is nothing yet in this proposal which would define how such a system would work.
> 5. I do not have enough knowledge of the functioning of the Swift compiler and build tools to know the impact of this approach.
> 6. Technically this does not preclude submodules as well, although I would suspect having both concepts would mean too much complexity.
> 
> Comments?
> 
> -DW
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170306/d6e4f3f9/attachment.html>