> On Mar 3, 2017, at 1:13 PM, Karim Nassar <[email protected]> wrote:
>
>>
>> On Mar 3, 2017, at 12:35 PM, David Hart <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> ### 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
>>> // MyModule
>>>
>>> submodule SubA
>>>
>>> ```
>>
>> Like the previous response, I think this potentially the weakest part of he
>> proposal. I like the idea of a file-system based submodule system but I'm
>> not sure I like this version of it. People are going to be very vocal about
>> this too. Perhaps you could rewrite the proposal with several solutions for
>> this part? Let people discuss the different solutions.
>
> Thanks, this is exactly why I posted this original concept—to spur
> conversation.
>
> An alternate approach might be to eliminate the “magic file” and directory
> dependency and replace them with explicit sub-module adoption per file.
> Something like this:
>
> **all spellings are straw-men!**
>
> ```
> // declared in any file
>
> // this is the same sub-module declaration previously declared in the magic
> file,
> // and serves the same purpose of declaring the sub-module,
> // and acting as a home for future configuration:
>
> submodule SubA
>
>
> // announced once in any file you wish to include in the sub-module:
>
> in_submodule SubA
>
> ```
>
> Some issues I see with this:
> increases the surface area— need to introduce a new declaration for
> announcing sub-module inclusion
> Either:
> introduces a new *kind* of declaration… `in_submodule` which can only appear
> once in a file (which would need to be compiler-enforced), OR:
> increases complexity by allowing multiple sub-module declarations in a file
>
Yet another possible approach is to treat the sub-module as a
symbolically-named scope (in plain-English, I’d call it a meta-type, but that
already means something). This is similar mechanically to one of the earlier
proposals:
```
submodule SubA { }
extension SubA {
struct Foo { }
submodule SubB {
struct Bar { }
}
}
extension SubA.SubB {
struct Bast { }
}
```
Pros:
* Extends an existing pattern in a somewhat reasonable-seeming way, easily
discoverable
Cons:
* Though the pattern *seems* reasonable, it’s actually an odd-duck; a
sub-module does not behave the same as a type in many important ways.
* There’s some impact here on how top-level declarations are evaluated (i.e.:
Protocols, global statements, etc).
* Visually uglier (indentation)
* The mental model required for this is **much** more complicated, as submodule
declarations can now be mixed within a file, and the (file)private Access
Controls will span sub-modules.
—Karim
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
