I dont agree. I think extensions serve this purpose very well. Here is what I
do:
I start with the type declaration only containing properties (public or
private). I then create one extension per access level required and one per
protocol conformance and per superclass overrides. We get:
class MyViewController: UIViewController {
public let publicProp: Int = 0
@IBOutlet private var tableView: UITableView!
}
//MARK: - Public
public extension MyViewController {
// Public functions
}
//MARK: - UIViewController
public extension MyViewController {
override func viewDidLoad() {
}
}
//MARK: UITableViewDataSource
extension MyViewController: UITableViewDataSource {
override func numberOfSectionsInTableView(tableView: UITableView) {
return 1
}
}
//MARK: Private
private extension MyViewController {
// Private functions
}
> On 13 Jun 2016, at 01:14, Raphaël Wach via swift-evolution
> <[email protected]> wrote:
>
> Yes, extensions serve a different purposes. It doesn’t seem right for me to
> just split every class content into 3 different extensions only to group
> together items with a similar access level.
> It would just make the codebase of a framework more messy. Access modifier
> block allows to not break the structure of a class but make it more easy to
> organize, to write and to read which seems nice for our « write less, achieve
> more » new favorite language, Swift. :)
>
> Raph
>
>
>
>> Le 13 juin 2016 à 10:04, Charlie Monroe <[email protected]> a écrit :
>>
>> Extensions can't have stored properties.
>>
>>> On Jun 13, 2016, at 9:59 AM, Robert Widmann via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> What does this do that breaking a structure down into local extensions with
>>> the appropriate level of access control doesn't?
>>>
>>> ~Robert Widmann
>>>
>>> 2016/06/13 0:55、Raphaël Wach via swift-evolution
>>> <[email protected]> のメッセージ:
>>>
>>>> Hello Swifters,
>>>>
>>>> While working on some framework programming, I had this idea that I would
>>>> like to share with you.
>>>> If some other people like it, I would be more than happy to write a
>>>> proposal.
>>>>
>>>> Here is a little draft I wrote as a starting point to discuss.
>>>> Sorry if there is mistakes, I am not an english native speaker.
>>>> Thank you for your feedback.
>>>>
>>>> ————————————————————————————————————
>>>>
>>>> Swift proposal: Access modifier blocks
>>>>
>>>> This proposal introduces a refinement of the way to define access modifier
>>>> and visibility scope.
>>>>
>>>> The current keywords private, internal and public are nice, simple to use
>>>> and makes sense. But, especially in the context of framework development,
>>>> it can quickly becomes messy and confusing to define the visibility for
>>>> each member variable, function or enum. Also it takes more time to write
>>>> and is not ideal to visualize the public interface of a class.
>>>>
>>>> If a class A has only a few members, that’s ok to write
>>>>
>>>> class A {
>>>> public var member1: Int
>>>> var member2: Int
>>>> private var member3: Int
>>>> }
>>>>
>>>> With a bigger class B, it will looks far less nice
>>>>
>>>> class B {
>>>> public var member1: Int
>>>> var member2: Int
>>>> private var member3: Int
>>>> public var member4: Int
>>>> var member5: Int
>>>> private var member6: Int
>>>> public var member7: Int
>>>> var member8: Int
>>>> private var member9: Int
>>>> public var member10: Int
>>>> private var member11: Int
>>>> var member12: Int
>>>> public var member13: Int
>>>> var member14: Int
>>>> private var member15: Int
>>>> }
>>>>
>>>> And now, it’s really messy, takes more time to write and we need to think
>>>> twice to visualize what could be the public interface of our framework.
>>>>
>>>> The purpose of this proposal is to allow the definition of the access
>>>> modifiers for a block of declarations.
>>>> Then our class B could be:
>>>>
>>>> class B {
>>>> // Ok then this is part of the public interface of my framework
>>>> public {
>>>> var member1: Int
>>>> var member4: Int
>>>> var member7: Int
>>>> var member10: Int
>>>> var member13: Int
>>>> }
>>>> // This can be used anywhere in my framework
>>>> internal {
>>>> var member2: Int
>>>> var member5: Int
>>>> var member8: Int
>>>> var member12: Int
>>>> var member14: Int
>>>> }
>>>> // Here remains my private stuff. Don’t touch it ! Leave me alone ! My
>>>> preciouuusss
>>>> private {
>>>> var member3: Int
>>>> var member6: Int
>>>> var member9: Int
>>>> var member11: Int
>>>> var member15: Int
>>>> }
>>>> }
>>>>
>>>> It increases readability, avoid to write many times the same keywords,
>>>> which is quiet boring, and helps visualizing the architecture of the
>>>> framework by highlighting what can create a dependency with other classes
>>>> inside the framework and with code outside of the framework.
>>>>
>>>> It might also be useful in protocols. For exemple, a protocol could define
>>>> a set of methods that can be called only inside the framework and another
>>>> public one that can be called from outside of the framework.
>>>> Classes defined outside of the framework could only implement the public
>>>> stuff in the protocol.
>>>>
>>>> It would have no impact on the existing code as the existing
>>>> private/internal/public on every single line would still work outside of
>>>> an access modifier block so developers could move to use this smoothly.
>>>>
>>>> ————————————————————————————————————
>>>>
>>>> Please, let me know if you like the idea.
>>>>
>>>> Cheers,
>>>>
>>>> Raph
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
