> On Feb 21, 2017, at 10:11 PM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
>> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>> On Feb 21, 2017, at 7:38 PM, Robert Widmann <devteam.cod...@gmail.com> 
>>> wrote:
>>> 
>>> Correct.  Because, in dividing the submodule across an extension, you have 
>>> placed what should be a private API into a differently-scoped location.
>> 
>> Okay. So is your submodule design not intended to address the "I want to 
>> encapsulate implementation details so they're only visible to several units 
>> of code in different files, but not the entire module" use case? Because if 
>> there's no way to scope a symbol to "everything inside this submodule, but 
>> nothing outside this submodule", I think it leaves that use case unserved.
> 
> Unless I’m missing something there is also another encapsulation-related 
> problem with the proposed design.  Let’s suppose for the sake of discussion 
> there was a `submoduleprivate` access modifier (intentionally ungainly and 
> not realistic).
> 
> // File 1
> module Foo {
>    // internal, visible to the whole module
>    class Bar { submoduleprivate var protectedState: Int = 0 }
> }
> 
> // File 2 - Has nothing to do with Foo at all
> import MyModule.Foo
> 
> module NotFoo {
>   // Hey, I need to see Bar.protectedState!!!
>   func totallyNotFoo() {
>       var bar = Bar()
>       bar.foosExposedPrivates = 42
>   }
> }
> 
> // ok, I’ll just add an extension to Foo so I can see submoduleprivate and 
> wrap what I need
> module Foo {

Oops, this should have been `extension Foo`, but otherwise I believe it is 
valid under this proposal.

>    // Hey, I’ll be nice and keep it fileprivate, but I could make it public 
> if I wanted to.
>    extension Bar {
>         fileprivate var foosExposedPrivates: Int {
>            // Yep, I’m inside Foo so I can see it’s submoduleprivate stuff
>            get { return protectedState }
>            set  { protectedState = newValue }
>         }
>    }
> }
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to