[swift-evolution] Yet Another Take on Swift Sub-modules

[Matthew Johnson]

> On Mar 4, 2017, at 9:56 AM, Karim Nassar <karim at karimnassar.com> wrote:
> 
> 
>> On Mar 3, 2017, at 5:21 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>>> 
>>> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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. 

I’ve actually been starting to come around to the idea of using the file system.  Not so much because I really like it, but because I have been considering further some of the drawbacks of other approaches.  

One big reason is that a submodule should form a scope and scopes should consist of code that is physically adjacent.  In practice this means it should reside in close proximity in the file system.  Allowing any file in a project to be a part of any submodule partly defeats the purpose of using them to structure a project internally.  If we’re going to be organizing the files in a submodule physically anyway maybe we should just take advantage of that fact and prevent a stray file in a distant part of the file system from being part of the submodule.

The second reason is that there is a big problem with placing a simple `submodule Foo` declaration at the top of each file in a submodule.  We all make typos from time to time.  This method makes it too easy to accidentally type `submodule Fooo` and end up in a submodule you didn’t intend.  This mistake would likely be caught relatively quickly but it seems silly to have a system subject to this kind of mistake.  This means we would end arbitrarily placing the declaration in one file and saying `extends submodule Foo` in the rest of the files.  Your design avoids the need to arbitrarily choose where to place the declaration and avoids the need for a declaration in the rest of the files.

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

I’m going to look at your new draft this afternoon while I’m working on updating my proposal.  I think you’ll find it much more to your liking than the original draft.  Perhaps we will be able to converge if we keep the discussion going.

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

The problem with a "Makes Sub-Module” on a group in Xcode is that groups do not mirror the file system.  Maybe a file system based submodule feature would motivate the Xcode team to support group structures that do mirror the file system better.  I hope that would be the case!  Unfortunately I don’t think we’d have a guarantee when reviewing the feature and there are significant practical implications for using the feature in Xcode without that kind of support.  We would probably just have to trust Apple to get this right.

> 
> —Karim
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170304/603ba056/attachment.html>