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
