> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution
> <[email protected]> wrote:
>
> It has been my hope that a lightweight module system will remove the need for
> `private` *and* `fileprivate`.
I really doubt it will. `private`/`fileprivate` works because you can also
access `internal` at the same time.
What I mean by that is, think about code like this:
// Foo.swift
public class Foo {
public init() { … }
func doBar() -> Quux {
return helper(in: randomRange())
}
private func helper(in range: Range<Int>) -> Quux {
…
}
}
// Bar.swift
public class Bar {
public static let shared = Bar()
func baz(with foo: Foo) {
let quux = foo.doBar()
process(quux)
}
private func process(_ quux: Quux) {
…
}
}
These classes have `public` APIs that are externally visible, `internal` APIs
for communicating with each other, and `private` APIs for implementation
details. Now try to reproduce the same design with submodules and
`public`/`internal` only:
public import MyMod.Foo
public import MyMod.Bar
module Foo {
public class Foo {
public init() { … }
??? func doBar() -> Quux {
return helper(in: randomRange())
}
func helper(in range: Range<Int>) -> Quux {
…
}
}
}
// Bar.swift
module Bar {
public class Bar {
public static let shared = Bar()
??? func baz(with foo: Foo) {
let quux = foo.doBar()
process(quux)
}
func process(_ quux: Quux) {
…
}
}
}
The `doBar()` and `baz()` methods have to be either exposed to third parties or
kept away from yourself. That's just not viable.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
