> On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution 
>> <swift-evolution@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.

        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@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