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

[Vladimir.S]

On 02.08.2017 14:11, Víctor Pimentel Rodríguez via swift-evolution wrote:
> On Wed, Aug 2, 2017 at 12:26 PM, Tino Heth via swift-evolution 
> <swift-evolution at swift.org <mailto: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:

Small offtopic.
Just wanted to note, that access level of 'private' method inside type declaration 
and method in 'private' extension is not the same.

In second case you have actually *fileprivate* access level for method6..method9.
So, strictly speaking, you can't move/group 'private' methods from type declaration 
into 'private extension' without explicitly marking each method in extension as 
'private'.

I do believe 'private extension' should mean 'real' private access, given other 
extensions of the type(and the type declaration itself) in same file now see private 
declarations. But as I understand, this sheep has sailed.

Vladimir.

> 
> 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
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>