> On Mar 21, 2017, at 6:43 PM, Jose Cheyo Jimenez <ch...@masters3d.com> wrote: > >> >> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Mar 21, 2017, at 8:26 AM, Slava Pestov <spes...@apple.com >>> <mailto:spes...@apple.com>> wrote: >>> >>>> >>>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> -1 on this as well for similar reasons. Places where I use fileprivate >>>> (aside from what was automatically migrated by Xcode) can be counted on >>>> fingers of one or two hands. >>>> >>>> I feel that this proposal is reverting something without offering an >>>> alternative solution. >>> >>> In what situations do you use Swift 3 private where fileprivate is not an >>> acceptable replacement? >> >> In my usage, I very rarely use fileprivate. To back this with numbers, a >> recent project I developed (i.e. without Xcode's automatic migration of >> private -> fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 >> uses of "private”. > > Do you have a way to tell how much of the private is effectible fileprivate? > (top level private usage)
Yes, 19 cases (out of those 160). Mostly for private classes or identifiers/constants. In another project (a framework I use in all my projects): private (total): 335 top-level private: 65 (out of those 335) fileprivate: 41 And I know about a place or two that's not properly written and if I refactored it properly, I'd get rid of another 20 fileprivates. In my experience (for me - please don't take it as if I am judging anyone - not at all), the use of fileprivate indicates either improper public API (and by public I mean even internal - exposed out of the file); or that there could be other mechanisms for handling this (protected scope for subclasses/enclosing types). > > > >> >> This is definitely a personal opinion, but I tend to limit access to members >> as much as possible to discourage/prevent their usage out of the scope they >> are intended for and to better design API that should be used out of the >> scope (public/internal). I feel this is a good thing for newcomers to a >> codebase (and myself coming back to a codebase after a year or two) as >> Xcode's autocompletion won't offer members that are not supposed to be >> called out of the scope (scope-private). >> >> As I've mentioned this during the discussion, I feel that current state of >> things encourages huge files (1000+ lines of code) as you can't define >> "protected" level access and migrate some of the code that implements e.g. >> accessibility to a different file without potentially exposing internal >> details to the rest of the module (if the extension in the other file needs >> access to private details, which is often the case). >> >> I feel that if there should be a change to the access levels, it should >> address this as well. The current solution based on reverting the original >> proposal only unnecessarily exposes implementational details to the rest of >> the file - at least in my codebase. >> >>> >>> Slava >>> >>>> >>>>> On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> >>>>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor <dgre...@apple.com >>>>>> <mailto:dgre...@apple.com>> wrote: >>>>>> >>>>>> Hello Swift community, >>>>>> >>>>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs >>>>>> through March 27, 2017. The proposal is available here: >>>>>> >>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md >>>>>> >>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md> >>>>> -1. I yield the remainder of my time to Drew Crawford who satisfactorily >>>>> explained my concerns. >>>>> >>>>> >>>>> -- >>>>> Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime >>>>> Wrangler >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
