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