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
