> On Mar 3, 2017, at 5:21 PM, Matthew Johnson <[email protected]> wrote: > >> >> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution >> <[email protected]> wrote: >> >> Changes that *are* necessary are: >> >> * Change the spelling of `internal` to `module` (making `module` the new >> default) >> * Introduce a new modifier `internal` to mean "Internal to the current >> sub-module and its child-sub-modules” > > Can you give concrete examples of use cases where a descendent submodule > needs access to symbols declared by an ancestor? I gave some thought to this > when drafting my proposal and came to the conclusion that this runs against > the grain of layering and is likely to be a bad idea in practice. If there > are use cases I didn’t consider I am very interested in learning about them.
On further reflection and examination of my notes, I think you’re right, and that the `internal` encapsulation should be purely horizontal. Will adjust to reflect that. >> ### Making a Sub-module >> >> To create a sub-module within a Module (or sub-module) is simple: The author >> creates a directory, and places a "sub-module declaration file" within the >> directory: >> >> ``` >> // __submodule.swift > > Why the double underscore prefix? To make it sort to the top in a file > browser? > > Is this file allowed to have any Swift code? Or is it limited to > submodule-related declarations only? If the latter, why not use an extension > such as `.submodule` or `.swiftmodule` to differentiate it from ordinary > Swift files and allow the submodule to be named by the name of this file? So, my reasoning was that by requiring a specific standard name for the declaration file, we guarantee that any directory can only describe one submodule. Prefixing the proposed name with underscores was simply a way of preventing naming collision with potential “real code” files (and yes, as a side-effect alpha-floating it to the top). Since the `submodule` declaration might expand to include statements & configuration about the sub-module, I see no reason to prohibit Swift code from existing in that sub-module declaration file… Disallowing/controlling that seems to be a style/linter concern. However, as I mentioned above, all the specific spellings (except `internal`) for the different concepts in this proposal are straw-men awaiting input. I’d say the addition of a new type of file extension raises some concerns for me, but there’s already been a lot of push back on the general idea of using filesystem structures to organize sub-modules, so the whole idea may be moot. Shortly, I’m going to update the original proposal gist reflecting all the comments I’ve received and part of that will be expanding the proposal section to include multiple alternate strategies for discussion, along with pros/cons for each. I’ll include a discussion on naming options for this file in this section. > If we’re going to use the file system to organize submodules this seems like > a reasonable approach. It allows larger submodules to have folder > hierarchies within them and also creates a central location for > submodule-related declarations. > > A primary flaw I see in this approach is that Xcode is the dominant IDE for > Swift and the way Xcode handles files is not conducive to file-system > organization. I really detest the way Xcode handles this and would vastly > prefer that it simply reflected the physical file system hierarchy but I > don’t think that will change any time soon. On the other hand maybe a file > system based submodule system in Swift would motivate the Xcode team to > better reflect the physical file system organization. My thoughts (hopes?) on this were that should Swift adopt such a mechanism for sub-modules, then part of Xcode’s integration of the feature would be to make it aware of sub-modules in a first-class way, so that the author wouldn’t have to manually manage the project files to take advantage of the feature. I’d envisioned either a new “Makes Sub-Module” property on Groups or a new “Sub-Module" mechanism alongside Groups & Folders in the project list. This may be wishful thinking on my part. —Karim
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
