[swift-evolution] Enhancing access levels without breaking changes
Charlie Monroe
charlie at charliemonroe.net
Sat Apr 8 08:09:34 CDT 2017
This seems like a nice compromise, though it introduces a "horizontal" issue of indentation. Not a huge issue IMHO, though I think some people may see it as a downside.
For me, it's +1, though.
> On Apr 8, 2017, at 2:03 PM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
>
> Imho there is a simple solution to reach the goals of SE-0169 without breaking compatibility:
> Just allow extensions inside type declarations.
>
> class MyVC: UIViewController {
> private let numberOfSections = 0
>
> extension: UITableViewDataSource {
> // Skipping the class and assume we want to extend the surrounding type
> func numberOfSections(in tableView: UITableView) -> Int {
> return numberOfSections
> }
>
> func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
> return 0
> }
> }
>
> private extension {
> // this would contain everything that shoudn't be visible for other extensios
>
> var secret: Int = 0
>
> public extension MyFriendClass {
> // oh, well, I make an exception here for a trustworthy type
> func checkSecret(of controller: MyVC) -> Bool {
> return controller.secret > 0
> }
> }
>
> private extension {
> // this is so secret, I'm not even allowed to copy it
> }
> }
>
> public func myMethod() {
> print("This is just a boring method")
> }
> }
>
> It has the downside of shifting code to the right (you could as well leave those extension-blocks unindented), but lots of advantages:
> - No change for private needed
> - It can be nested as much as you like to satisfy even the most absurd desires of encapsulation
> - It reminds me on operator definitions inside type declarations
> - No change for fileprivate needed (but actually, I think there is very little need to keep fileprivate)
>
> I wish this would only be a joke, but writing the example, I actually started liking the concept (but I have a terrible headache right now which might affect my mind) — so either this receives some feedback, or I might start re-proposing this ;-)
>
> - Tino
> _______________________________________________
> 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/20170408/a08b97d7/attachment.html>
More information about the swift-evolution
mailing list