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
