[swift-evolution] [Proposal][Discussion] Modular Swift

[Xiaodi Wu]

On Tue, Feb 21, 2017 at 8:15 PM, Robert Widmann via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution <
> swift-evolution at swift.org> 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.
>
>
> If they must communicate, they can be a part of the same (sub)module.
> This makes filling in these annotations trivial.  Nobody actually uses
> modules to wall off their own APIs from themselves like this, they use
> submodules to encapsulate the internal parts and surface public APIs in the
> parent.
>

I think you'll find a ton of people on this list who would want to use
submodules precisely to wall off their own APIs from themselves. Witness
the hundreds of messages about new syntax to do just that.


>
> module Bar {
>
> public class Foo {
>
> public init() { … }
>
>
>
> internal func doBar() -> Quux {
>
> return helper(in: randomRange())
>
> }
>
>
> internal func helper(in range: Range<Int>) -> Quux {
>
> …
>
> }
>
> }
>
> }
>
>
> // Bar.swift
>
> extension Bar {
>
> public class Bar {
>
> public static let shared = Bar()
>
>
> internal func baz(with foo: Foo) {
>
> let quux = foo.doBar()
>
> process(quux)
>
> }
>
>
> internal func process(_ quux: Quux) {
>
> …
>
> }
>
> }
> }
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/7781f9f4/attachment.html>