And if you want to be able to declare properties in extensions, which I'm not a
fan of, I think it would still be more a appropriate proposal than one that
adds another way to group access modifiers.
> On 14 Jun 2016, at 13:18, David Hart via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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
>> <swift-evolution@swift.org> 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 <char...@charliemonroe.net> a écrit
>>> :
>>>
>>> Extensions can't have stored properties.
>>>
>>>> On Jun 13, 2016, at 9:59 AM, Robert Widmann via swift-evolution
>>>> <swift-evolution@swift.org> 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
>>>> <swift-evolution@swift.org> のメッセージ:
>>>>
>>>>> 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
>>>>> 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
>>
>> _______________________________________________
>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
