[swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

[Víctor Pimentel Rodríguez]

On Wed, Aug 2, 2017 at 12:26 PM, Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

>
> That would work as well, but it has the downside of forcing a potentially
> huge number of methods to be implemented in a single place, reducing the
> readability as opposed to packing them into semantically related groups in
> the form of extensions.
>
> I really don't get why people are so obsessed with same-file extensions:
> They are recommended in style guides, influencers blog about them, and
> they motivated a ridiculous complex change in the access rights system. Yet
> I haven't seen any evidence that they offer real benefit.
> Extensions are great for adding useful helpers to existing types, and
> still allow you to selectively expose details of your own classes — but
> most people seem to ignore those options and focus on something can be done
> better with plain old comments.
> [sorry for the rant — but I think a critical look at extensions is long
> overdue: I rarely see someone questioning their role, so basically, we are
> making important decisions based on pure superstition]
>
> A protocol itself is already a vehicle to group related methods, and if
> you have a huge entity, it doesn't get better just because you split it and
> hide its complexity.
>

In my organization we use same file extensions to group methods by
visibility (and also by protocol conformance), so instead of:

public class MyClass {
    public func method1() {}
    public func method2() {}
    public func method3() {}
    public func method4() {}
    public func method5() {}
    private func method6() {}
    private func method7() {}
    private func method8() {}
    private func method9() {}
}

We write:

public class MyClass {
}

public extension MyClass {
    func method1() {}
    func method2() {}
    func method3() {}
    func method4() {}
    func method5() {}
}

private extension MyClass {
    func method6() {}
    func method7() {}
    func method8() {}
    func method9() {}
}

The main reason is not having to repeat the visibility modifier, although
this brings several other advantages and makes our code style more
consistent and easier to follow:

- It forces us to put the private methods at the end of the file, and
that's good because they are implementation details and thus not the first
thing a reader should see. You could do this with comments, but the
syntactic separation seems stronger.
- It makes trivial switching the visibility of the "public methods". For
example we extracted some frameworks from our app and thanks to this
organization it was trivial to change every internal definition to public
ones.
- It also works with other modifiers like @objc.

-- 
Víctor Pimentel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170802/b361116e/attachment.html>