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@swift.org <mailto:swift-evolution@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@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
