No need to rename fileprivate; it's irrelevant to your use case and is resurrecting a bikeshedding discussion that really needs to be put to rest.
The proposal is essentially for something like @testable for fileprivate members. Sounds fine to me. On Mon, Oct 17, 2016 at 09:35 Jonathan Hull via swift-evolution < [email protected]> wrote: > On Oct 16, 2016, at 3:28 PM, T.J. Usiyan <[email protected]> wrote: > > I don't like this at all and it comes down to "what is hidden can also > be unhidden". This, to me, feels like it would create more confusion than > it would address. > > I don’t think it would cause confusion. Other languages have things like > protected, which is currently a glaring hole in Swift’s access control. > This addresses that without any of the complexity of friend classes, etc…. > > > Why not just use `internal` for `hidden` items? > > Because there is an important aspect of communicating the author’s intent. > > I think it is important to be able to mark things which are not meant to > be public (and internal is essentially public in the main module), but may > be required by extensions/subclasses. With internal, it would be easy to > accidentally create tightly coupled structures. With ‘hidden', it requires > intentional annotation (via the ‘include hidden’ statement) to gain access, > so more thought will be given to the coupling. > > Also, internal would prevent extensions/subclasses outside the defining > module. With ‘hidden’ you have an author approved way of extending a type > (even from another module). I can’t actually think of a single use of > ‘fileprivate’ where my intent/need was something other than allowing > extensions. Unfortunately, with the current model those files can get quite > a bit bigger than is ideal from an organizational standpoint. > > > If we're ok with modifying import statements, why not simply have a > command that imports `fileprivate` stuff? (not advocating for this). > > From a technical perspective, that is essentially what I am proposing, but > terminology matters. The word fileprivate was chosen to convey that the > associated item was private to scope of the file. With this, we need to > convey a slightly different intent because, while it does open access at > file granularity, it is no longer private to the scope of that single file, > and the name would be misleading. > > It doesn’t need to be the word ‘hidden’ necessarily, but it should be > something with the correct connotation for the new behavior. > > > I think that submodules would have really helped with this issue and it is > unfortunate that we couldn't get them in for swift 3. > > I also want submodules, but they won’t fully solve the protected problem > above. They would allow you to group KNOWN subclasses and extensions into > a single submodule. But they would also prevent further extensions and > subclasses from being made by the consumer of that module. If that is what > you want, then submodules are the answer, but there are also lots of cases > where an author wants to allow careful subclassing outside of the original > module. > > A good example of this is UIGestureRecognizer, which separates its > protected items into a different include. It hides all of the dangerous > properties/methods in that separate file, and 98% of the time you don’t > need it. However, if you want to create your own gesture recognizer, you > can’t really do it without those dangerous methods… thus you include the > file. With the submodule approach, you would either be unable to create > your own gesture recognizer subclasses or the dangerous methods would be > made available inappropriately. > > > Thanks, > Jon > > > On Sun, Oct 16, 2016 at 4:34 PM, Jonathan Hull via swift-evolution < > [email protected]> wrote: > > I keep wanting a “protected” access level, but I must also admit that > there was something really elegant about Swift 2’s access scheme (and I > think most of us feel like the word ‘fileprivate’ feels out of place). I > was thinking about how to mesh those two ideas, and I think I may have come > up with a solution. > > I propose we replace ‘fileprivate’ with a new ‘hidden’ access level. > Hidden would work exactly the same way as fileprivate does now, but adds > the connotation that what is hidden can also be unhidden. By adding > ‘import hidden TypeName’ to another file, that file also gains access to > all of the hidden items of that type (kind of like if it was in the same > file). > > #FileA > import Foundation > > Struct A { > private var x:Int > hidden var y:Int //This is just like fileprivate, but can > also be shared with other files > } > > extension A { > //y can be accessed here because they are in the same file > } > > > #FileB > import Foundation > import hidden A //This allows the entire file to see A’s hidden > variables > > extension A { > //y can be accessed here because of the ‘import hidden’ > declaration > } > > > #FileC > import Foundation > > extension A { > //y can NOT be seen or accessed here because it is hidden > } > > > I think this is a fairly elegant solution to our protected dilemma, which > also feels in sync with Swift 2’s file-based scheme. The key features: > • Extensions no longer need to be piled in the same file if it is > getting too long > • Subclasses can be in their own file, but still have access to > the necessary parts of their superclass > • It communicates the author’s intent that the items are not meant > to be visible to its users, but that it is expected to be used for > extension/subclassing > • It requires an explicit statement ‘import hidden’ to access the > hidden variables. Safe by default, with override. > • It is not bound by module boundaries (i.e. you could use it for > subclassing classes from an imported module) > • Roughly the same length as ‘private’ and ‘public’ so various > declarations packed together are much easier to read (fileprivate breaks > reading rhythm) > > Worth a formal proposal? > > Thanks, > Jon > > > > _______________________________________________ > 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
