This level of access, the “private to this submodule except to the select set
of interfaces I want to see it” level, is the equivalent of friend classes in
C++. I don’t consider leaving this out to be a hole, nor is it an
"encapsulation-related problem” because at no point can you break the API
boundary and re-export anything here with a higher level of access than it had
previously.
> On Feb 21, 2017, at 11:13 PM, Matthew Johnson <matt...@anandabits.com> wrote:
>
>
>> 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 Foo {
>> 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
