> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
>
>> On Feb 21, 2017, at 7:38 PM, Robert Widmann <[email protected]> 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 {
// 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
