Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?
@Jim You most certainly offended no one! Quite the opposite. This being an open source community, every contribution counts and, imho, you did nothing but to *contribute *to swift's evolution! Thanks for backing typeprivate proposal. We have been looking for ways to restructure our proposal based on all the fine arguments raised by everyone during the discussion, however we have not found time to complete it. We will definitely keep in touch in the following days. I believe your proposal really relates to ours. The real urge is to revisit access level controls, if need it be, and create finer grained modifiers for better communication. @Derrick This being said, the solution might even reduce the number of access control modifiers and not just add one more to the pile. I think we all aim to have the right amount of modifiers for the right amount of use cases. Should they be organised and designed in a way that better conveys their intent, then I believe the number will not be the number one problem. @Tino I do agree with you. It is sometimes hard to keep track of all the proposals/discussions being raised. While I do believe this is an open enough forum for everyone to participate in, it can become quite hard to have the full spectrum of discussions in sight at first glance. Best, Gonçalo 2016-12-08 18:51 GMT+00:00 Tino Heth <2...@gmx.de>: > Hi Jim, > > > This is my first use of this forum. I certainly did not mean to cause > pain for anyone. > > I hope I didn't sound as if I was blaming you — imho it is not realistic > to keep track of the evolution process as it is organised now, so even > exact repetition is rather common > > > At Gonzalo's invitation I have looked over the thread for his proposal > and I am withdrawing my request and backing his with a very heavy +1. > This one? https://github.com/goncaloalvarez/swift-evolution/blob/master/ > proposals/-introduce-typeprivate-access-control-level.md > > > If I have offended anyone I ask their forgiveness. Since you mentioned > it I will state that the Xcode approach to project groups is one that I > have yet to understand the merit of. > > Gonzalo: please let me know how I can assist you. > I don't think anyone is offended, and imho your offer to Gonzalo is a good > move (it's just sad that there is no established tool for such > collaboration) ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level
"The thing is, typeprivate cannot replace fileprivate, just because fileprivate adds internal visibility to other scopes inside the same file and does not restrict it to the same type. And I really love that aspect of Swift. :)" While I do see the advantages in exposing members within the same file, we must agree that can promote somehow odd patterns of chunking code into the same file. As I said before, that's definitely not the intent, however there's no mechanism of preventing it. I believe typeprivate would definitely help in scoping and improving code readability while we're at it! private // like `private(scope)` private(file) // like `internal(file)` private(type) // in your case I must say I am very fond of this solution as well. It clearly conveys the idea. "PS: I also cannot wait for existentials to drop typealias ProtoB = Any where Proto.A == B where B comes from a generic parameter list and A is an associated type." Same here! Best, Gonçalo 2016-12-02 11:58 GMT+00:00 Adrian Zubarev : > IMO there is no need for something like typepublic to even exist, but in > theory it would be something like where a subclass has more visibility of > the internal stuff of its super type. I’m just saying that someone will > want this, because that person might thing that typepublic and typeprivate > would be consistent. > > In general I’m for anything that adds flexibility, but flexibility means > also more complexity. > > The thing is, typeprivate cannot replace fileprivate, just because > fileprivate adds internal visibility to other scopes inside the same file > and does not restrict it to the same type. And I really love that aspect of > Swift. :) > > It already has been discussed thousands of times but I cannot resist and > also state my preference to something like: > > private // like `private(scope)` > private(file) // like `internal(file)` > private(type) // in your case > > -- > > This is a POP language right? So lets focus on fixing and improving > protocols. :) We should start with open/public protocol. > -- > > PS: I also cannot wait for existentials to drop typealias ProtoB = > Any where Proto.A == B where B comes from a generic parameter list > and A is an associated type. > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 2. Dezember 2016 um 12:36:45, Gonçalo Alvarez Peixoto ( > goncalo.alvarezpeix...@gmail.com) schrieb: > > Also, would you be so kind to provide an example where typepublic would be > useful? Maybe you're thinking of allowing member access to subclasses? > Would that fall into a possible "protected" realm? > > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level
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 > : Access is granted to the type named > file: Access is limited to this file only > : Access is granted to the named file > module: Access is granted to the entire module > : 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: > > . > . > .. > > Read/write control through a parameter passing notation: > > .([[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 < > swift-evolution@swift.org> 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 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/-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 > >> 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
Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level
@Brandon *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. * .Most definitely. We've mentioned earlier in this thread the usage of file private feels somehow we're basing swift design on compiler related constructs. *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). * *.*Agreed. As stated before, this might lead into some kind of pattern where types are chunked into the same file for the sakes of member access convenience. I strongly believe we should aim at promoting code clarity and readability while enhancing single responsibility principle's good practices. *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. * Don't you feel that would defeat the purpose of access control levels? Correct if I'm wrong, but I don't think there's much to gain from trying to dodge the need for private (whether scope private, fileprivate or eventually typeprivate) members no matter how modularised your code is. Also, I believe it an unworthy effort, as I think we could run the risk of creating problems further in the chain of access control levels? I just think we'd be pushing the problem further up the hill. Best, Gonçalo 2016-12-01 20:40 GMT+00:00 Brandon Knope : > > > > This keeps leading me back to having submodules or creating modules on > demand. I think that would open up this system to great complexity. > > I meant "flexibility"...not complexity. Freudian slip? 😂 > > Brandon ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level
@Aron, I did take a look at that document while developing the proposal. As you stated, it's a little old, however the principles of access control and their purpose remain pretty much the same. ".keep private details of a class hidden from the rest of the app .keep interna details of a framework hidden from the client app" Both these rules still get respected with the introduction of a new level of access control. *typeprivate *would not allow for member access within any other then the *type* itself. @Jay, while I do appreciate your idea, I'm afraid this proposal aims at something a lot less complex. One may argue the changes in Swift's design to accommodate it may facilitate and open door to more complex changes like the one you suggest, still I believe those changes are most welcome in the name creating a safer and easier to handle access control policy. This proposal aims only at opening access to private members to any extension over that type. 2016-12-01 17:47 GMT+00:00 Martin Waitz via swift-evolution < swift-evolution@swift.org>: > Hi, > > Am 2016-12-01 11:08, schrieb Álvaro Monteiro via swift-evolution: > > - Typeprivate would allow to abandon the odd fileprivate. Access level > > would be constrained to swift constructs (structs, classes and > > extensions) and not to a compiler artifact (file). > > Files are not compiler artifacts but design artifacts. > They group related stuff which was designed together and which should be > reviewed together. > > I really like `fileprivate` and how Swift currently handles access control. > > -- > Martin > ___ > 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
Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level
*@Daniel* I am very fond of your idea, as I believe it add extra flexibility to this solution, as Álvaro mentioned. My only concern is somehow related to semantics. Should we add the extra scope detail as you suggest, then it could clash with the current way of setting a setter as private or fileprivate: Current: fileprivate(set) Suggested: private(file)(set) Still, of all the hurdles one might face, this one I believe is definitely the one that poses the less threat! *@Tino* As you imply on a previous email, this solution might even facilitate the introduction of new levels of access control all throughout modules, whether internally and externally. While I do agree complexity does raise an issue in designing a fine solution for access control, I insist this concern should not block the language's evolution into finer grained control and better focused levels of scope. Quoting Álvaro: "communication is something that everyone agrees is a essential in swift and access control is one of the many ways developers have to properly describe (and communicate) an API." Also Tino, you state: "The question for me is how much complexity should be accepted as a tradeoff for increased expressiveness? "private, internal, public" was quite simple, but the current system is already quite complicated, and it doesn't scale well." In fact, I consider this change a great opportunity for the current system to be revisited in a gradual manner. As to the equatable issue you pointed out, is there a reason why replacing the fileprivate access control level by with a typeprivate would not solve the problem raised with private? There's yet another issue I would like to reinforce, one raised on previous emails. As stated before, I do believe fileprivate, as a compiler related construct, opens the door for one to access members from another member, as long as they'r all sitting within the same file. This creates conditions for a odd and dangerous pattern. While I don't think fileprivate aims at promoting several type implementation within the same file, it certainly opens that door. That's one pattern a typeprivate access control level would grant no advantages in using. Best, Gonçalo ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level
Hello, Tino! Thanks for your feedback. I do suggest an alternative, in which *typeprivate *replaces file private, since I believe that having the scope of a member limited by file scope does does fall short in fitting a language design purpose, as file is a compiler related construct which could, in turn, be replaced somewhere in time, thus leaving the “fileprivate” access member orphaned. I should not be accessed from another module, since that's what *internal* is for. *typeprivate *would still create a private context. Best, Gonçalo 2016-11-29 16:16 GMT+00:00 Tino Heth <2...@gmx.de>: > As you pointed out, Swift already has quite a lot access levels… > Comparing the usefulness, "typeprivate" would clearly win over (Swift 3) > "private" for me — but it adds a "new dimension" to the game, and I guess > this will be a dealbreaker: > Should it be possible to access typeprivate data from another module in an > extension or subclass? > > - Tino ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level
Hey, Robert! Thanks for your feedback. I do believe that it is a common practice, and a good one as well, to have your code broken down into separate extensions, either for improving code readability by reducing the size of the implementation file, as well as creating context for feature development. Also, I do agree that one should have separate classes, structs, enums or whatever better fits the purpose, handle code regarding a single responsibility. However, should this responsibility remain within the scope of the type we're implementing it on, it's best to have the code split into separate extensions on separate files (so to avoid large and hard to inspect files), and have these extensions access members which, would *no longer* *be visible* to the whole module. I do believe, having these members marked as *internal* creates the conditions for one to *scatter* and *decompose *a type since it opens the door for type in the module to lay hands on it's members. *Typeprivate* would prevent these members to be accessed from everywhere in the module, while enabling them to be reached from everywhere within their type. Also, I believe that having the scope of a member limited by file scope does does fall short in fitting a language design purpose, as file is a compiler related construct which could, in turn, be replaced somewhere in time, thus leaving the “fileprivate” access member orphaned. Best, Gonçalo 2016-11-29 16:13 GMT+00:00 Robert Widmann : > Is that a particularly common case? I haven’t written code that needs > access patterns like this and it strikes me as strange that anything you’re > willing to expose to extensions scattered throughout your codebase you’d > also prefer not to export throughout a module that you have complete > control over. Sure, it might be “cleaner” to scope your variables to the > implementation, but past a certain point it just seems to encourage extreme > decomposition and scattering of a single class or structure when you should > be separating your implementation into multiple classes and structures. > > On Nov 29, 2016, at 11:07 AM, Gonçalo Alvarez Peixoto < > goncalo.alvarezpeix...@gmail.com> wrote: > > Robert, > > Thanks for your feedback. > > However, I tend to disagree with you. > > *"The proposal, as it stands, does nothing to indicate how this is much > different from internal - all examples given would trivially be solved by > internal members."* > This proposal aims at covering all of the cases in which you *do not want* to > expose your properties *internally. *For instance, you might want to > access a member of a view controller from an extension of this view > controller on another file, but not make it accessible from other members > in the module (which is what *internal *does). > > Best, > Gonçalo > > 2016-11-29 15:53 GMT+00:00 Robert Widmann : > >> The proposal, as it stands, does nothing to indicate how this is much >> different from internal - all examples given would trivially be solved by >> internal members. I don’t think we need finer-grained access control to >> address this, I think we need extensions, at least in the same file as >> their parent declarations, to be able to define variables. >> >> On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution >> 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/maste >> r/proposals/-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 >> 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
Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level
Robert, Thanks for your feedback. However, I tend to disagree with you. *"The proposal, as it stands, does nothing to indicate how this is much different from internal - all examples given would trivially be solved by internal members."* This proposal aims at covering all of the cases in which you *do not want* to expose your properties *internally. *For instance, you might want to access a member of a view controller from an extension of this view controller on another file, but not make it accessible from other members in the module (which is what *internal *does). Best, Gonçalo 2016-11-29 15:53 GMT+00:00 Robert Widmann : > The proposal, as it stands, does nothing to indicate how this is much > different from internal - all examples given would trivially be solved by > internal members. I don’t think we need finer-grained access control to > address this, I think we need extensions, at least in the same file as > their parent declarations, to be able to define variables. > > On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution < > swift-evolution@swift.org> 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/-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 > 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] Swift evolution proposal: introduce typeprivate access control level
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/-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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
