Access modifier blocks


(Raphaël Wach) #1

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


(Robert Widmann) #2

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


(Charlie Monroe) #3

Extensions can't have stored properties.

···

On Jun 13, 2016, at 9:59 AM, Robert Widmann via swift-evolution <swift-evolution@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@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


(Raphaël Wach) #4

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. :slight_smile:

Raph

···

Le 13 juin 2016 à 10:04, Charlie Monroe <charlie@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@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@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


(David Hart) #5

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 <swift-evolution@swift.org> 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. :slight_smile:

Raph

Le 13 juin 2016 à 10:04, Charlie Monroe <charlie@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@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@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #6

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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org> 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. :slight_smile:

Raph

Le 13 juin 2016 à 10:04, Charlie Monroe <charlie@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@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@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

_______________________________________________
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


(Charlie Monroe) #7

Your approach has a major flaw: methods from extensions can't be overridden (at least for now). As long as you want to your controller to be subclassed and allow overriding your public/internal methods, you need to move them from extensions to the main class scope. Which simply sucks and may be fine for final classes (or classes that you don't plan on subclassing), but is in no way a good way to design a root class which is meant to be subclassed.

I am kind of on and off on this proposal - I like the way you can group vars together based on access control, but I'd leave it at that, not extending it to methodsm since it would introduce horizontal space issues (code starting at indentation level 4).

···

On Jun 14, 2016, at 10:18 PM, David Hart <david@hartbit.com> 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 <swift-evolution@swift.org> 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. :slight_smile:

Raph

Le 13 juin 2016 à 10:04, Charlie Monroe <charlie@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@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@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ross O'Brien) #8

Your style may vary, but in my experience the access level of two functions
has very little effect on how they should be grouped.

Let's take an example: a class with two init functions. (If you want a
concrete example: a subclass of UIView has init(frame) and init(coder)).
While the inits take different arguments, they share a lot of
initialisation steps, so to avoid unnecessary duplication, we create a
private 'sharedInitialisation()' function which both init()s call once
they've set the class's values.

For readability's sake, in the Swift file, I write the two init() functions
one after the other, and then I write the sharedInitialisation() function
immediately below them. That way they're all on the screen simultaneously -
I don't need to click or scroll to the 'private extension' to understand
how this class is set up.

If the intent of this is to group functions together so that it's easier to
find only the ones which can be called from the internal/public levels,
then I think there are better ways. Xcode generates interface counterpart
files of Swift types which strip the type and its functions to just their
declarations.

Are there other advantages to segregating functions by access levels?

Ross

···

On Tue, Jun 14, 2016 at 9:21 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote:

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 < > swift-evolution@swift.org> 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 < > swift-evolution@swift.org> 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. :slight_smile:
>>
>> Raph
>>
>>
>>
>>> Le 13 juin 2016 à 10:04, Charlie Monroe <charlie@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@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@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
>>
>> _______________________________________________
>> 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Raphaël Wach) #9

Also, even if the sample code with the 3 extensions might looks ok, think that if you’re working on a 300 classes project, declaring 900 extensions seems a crazy thing to do. I would not have to do this on a big project.

@Charlie: Agree with you, on second thought, the implication of extending the use of access modifier blocks to functions and protocols seems a bit tricky and could increase the indentation level of the code in an annoying way. So, I would go with a proposal limited to vars/constants/properties items.

···

Le 14 juin 2016 à 23:46, Charlie Monroe <charlie@charliemonroe.net> a écrit :

Your approach has a major flaw: methods from extensions can't be overridden (at least for now). As long as you want to your controller to be subclassed and allow overriding your public/internal methods, you need to move them from extensions to the main class scope. Which simply sucks and may be fine for final classes (or classes that you don't plan on subclassing), but is in no way a good way to design a root class which is meant to be subclassed.

I am kind of on and off on this proposal - I like the way you can group vars together based on access control, but I'd leave it at that, not extending it to methodsm since it would introduce horizontal space issues (code starting at indentation level 4).

On Jun 14, 2016, at 10:18 PM, David Hart <david@hartbit.com> 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 <swift-evolution@swift.org> 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. :slight_smile:

Raph

Le 13 juin 2016 à 10:04, Charlie Monroe <charlie@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@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@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #10

Feel free to move the further discussion into my thread with an enhanced mechanism called group. Thread link.

···

--
Adrian Zubarev
Sent with Airmail

Am 19. Juni 2016 um 20:24:31, Raphaël Wach via swift-evolution (swift-evolution@swift.org) schrieb:

Also, even if the sample code with the 3 extensions might looks ok, think that if you’re working on a 300 classes project, declaring 900 extensions seems a crazy thing to do. I would not have to do this on a big project.

@Charlie: Agree with you, on second thought, the implication of extending the use of access modifier blocks to functions and protocols seems a bit tricky and could increase the indentation level of the code in an annoying way. So, I would go with a proposal limited to vars/constants/properties items.

Le 14 juin 2016 à 23:46, Charlie Monroe <charlie@charliemonroe.net> a écrit :

Your approach has a major flaw: methods from extensions can't be overridden (at least for now). As long as you want to your controller to be subclassed and allow overriding your public/internal methods, you need to move them from extensions to the main class scope. Which simply sucks and may be fine for final classes (or classes that you don't plan on subclassing), but is in no way a good way to design a root class which is meant to be subclassed.

I am kind of on and off on this proposal - I like the way you can group vars together based on access control, but I'd leave it at that, not extending it to methodsm since it would introduce horizontal space issues (code starting at indentation level 4).

On Jun 14, 2016, at 10:18 PM, David Hart <david@hartbit.com> 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 <swift-evolution@swift.org> 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. :slight_smile:

Raph

Le 13 juin 2016 à 10:04, Charlie Monroe <charlie@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@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@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

_______________________________________________
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