And the funny thing is, we don’t actually _need_ access control levels. The only purpose of access control is to enhance security/reliability by imposing restrictions on other programmers (API users).
It seems to me that in almost all discussions the arguments are mostly backwards: i.e. formulated from the perspective of the API users. Maybe because just about all programmers are API users of the OS-API? Anyway… What I would like to see is a complete overhaul of the access control and rewrite it entirely from the perspective of the API provider. I.e. give a more fine grained control to the API writer in the sense that he can specify exactly which other piece of code has access. I consider it dangerous by default to open up a scope just because another class needs occasional access. (i.e. give -for example- module access just because there is 1 other class in the module that needs that access. Inadvertently opening up access to all other classes in that module.) An access control list could do just that. Perhaps something like: access(type, MyFriendClass(get)) The above would provide access to the entire type (but not any children) and read-only from MyFriendClass. A quick -off the cuff- list of access levels: local: access only to local scope (default) type: Only the type in which it is defined (no children) child: The type and its children <type-name>: Access is granted to the type named file: Access is limited to this file only <file-name>: Access is granted to the named file module: Access is granted to the entire module <module-name>: Access is granted to the module with the given name public: Access is granted to everybody Further access specification could be made possible through the use of the dot-notation: <type-name>.<function-name> <file-name>.<class-name | function-name> <module-name>.<class-name>.<function-name> Read/write control through a parameter passing notation: <type-name>.<function-name>([[get],][set]) Examples: access(type) var count: Int // entire type can read/write access(type(get), type.incrementer) var count: Int // Entire type can read, only the incrementer function has read/write access(module, FriendType, public(get)) var count: Int // Entire module can read/write, FriendType can read/write, others can only read Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 01 Dec 2016, at 21:38, Brandon Knope via swift-evolution > <[email protected]> wrote: > > Is anyone starting to think the current access control model will become more > burdensome over time? > > People will want to add and subtract to it for years to come...which tells me > it's not very flexible. I'm beginning to feel like it is an old style model > trying to fit into a modern language. > > For example, fileprivate and private encourage stuffing a lot of code into > one file just to use that access control level. If you want to break this > into more manageable chunks you have to make it internal or move it into a > new module which is very complicated to do in Xcode (I.e requiring a new > target like a framework). > > This keeps leading me back to having submodules or creating modules on > demand. I think that would open up this system to great complexity. > > Want to keep something private to a specific class but private to anything > outside of it? Make it internal to the same "submodule". > > I think we could keep tacking on things to access control, but I don't think > it is really solving everyone's needs. I think a more flexible system would > allow people to adapt it to their needs instead of structuring everything > around a rigid system that forces you to do it swift's way. > > On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution > <[email protected]> wrote: > >> Hello, everyone! >> >> I would like to introduce a new proposal to swift evolution, but first I >> would love to run it by all of you so I get everyone's feedback and enrich >> it. >> >> This proposal consists of introducing a new typeprivate access control level >> which allows for members to be accessed in all extensions of a given type, >> whether lying within or in another file. >> >> You'll find the proposal draft in: >> https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md >> >> Thanks in advance for taking the time to evaluate the proposal. >> >> Best regards, >> Gonçalo >> _______________________________________________ >> 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
