[swift-evolution] Access modifier blocks

[Raphaël Wach]

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 <charlie at 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 at 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 at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>