[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels
Pranshu Goyal
pranshu.goyal at novanet.net
Tue Mar 21 05:16:24 CDT 2017
-1
I second Drew Crawford's opinion. Although I agree with some of the
critiques about the current state of access levels in swift, I don't
believe that this would be the right way to proceed.
On 21 March 2017 at 06:56, Drew Crawford via swift-evolution <
swift-evolution at swift.org> wrote:
> I disagree quite strongly with the proposal.
>
> First, the document draws conclusions without apparent supporting
> evidence, e.g.
>
> > Since the release of Swift 3, the access level change of SE–0025 was met
> with dissatisfaction by a substantial proportion of the general Swift
> community. Those changes can be viewed as actively harmful, the new
> requirement for syntax/API changes.
>
>
> - What is “dissatisfaction by a substantial proportion of the general
> Swift community”? How was this measured/determined?
> - What was done to control for the population happy with SE-0025 who
> would e.g. not be likely to take up pitchforks?
> - Who argues these changes are “actively harmful” and where were they
> during SE-0025?
>
> > subtly encourages overuse of scoped access control and discourages the
> more reasonable default
>
>
> - Who claims that scoped access is “overused” and what is their
> argument for doing so?
> - Why is “fileprivate” the “more reasonable default”? In fact neither
> fileprivate **nor** private are default (reasonable or not!). Internal
> is the default. Nor does this proposal suggest we change that. So this
> seems a very strange statement.
>
> > But is that distinction between private and fileprivate actively used by
> the larger community of Swift developers?
>
> Yes. To cite some evidence, here are codebases I actively maintain:
>
> | codebase | private # |
> fileprivate # | ratio |
>
> |--------------------------------------------------------|--
> ---------|---------------|-------|
>
> | "M" (proprietary) | 486 | 249
> | 2x |
>
> | "N"(proprietary) | 179 | 59
> | 3x |
>
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15 | 1
> | 15x |
>
> | atbuild https://github.com/AnarchyTools/atbuild | 54 | 5
> | 11x |
>
> So from my chair, not only is the distinction useful, but scoped access
> control (private) is overwhelmingly (2-15x) more useful than fileprivate.
>
> > And if it were used pervasively, would it be worth the cognitive load
> and complexity of keeping two very similar access levels in the language?
> This proposal argues that answer to both questions is no
>
> This proposal does not make any later argument about “cognitive load” or
> “complexity” I can identify. Did the proposal get truncated?
>
> What is stated (without evidence) is that "it is extremely common to use
> several extensions within a file” and that use of “private” is annoying in
> that case. I now extend the above table
>
> | codebase | private # |
> fileprivate # | ratio | # of extensions (>=3 extensions in file) |
>
> |--------------------------------------------------------|--
> ---------|---------------|-------|--------------------------
> ----------------|
>
> | "M" (proprietary) | 486 | 249
> | 2x | 48 |
>
> | "N"(proprietary) | 179 | 59
> | 3x | 84 |
>
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15 | 1
> | 15x | 3 |
>
> | atbuild https://github.com/AnarchyTools/atbuild | 54 | 5
> | 11x | 6 |
>
> in order to demonstrate in my corner of Swift this is not “extremely
> common”, and is actually less popular than language features the proposal
> alleges aren’t used.
>
> My point here is that ***different people in different corners of the
> community program Swift differently and use different styles***. I can
> definitely empathize with folks like the author who use extensions to group
> functions and are annoyed that their favorite visibility modifier grew four
> extra characters. Perhaps we can come up with a keyword that is more
> succint.
>
> However, that is no reason to take away features from working codebases.
> A scoped access modifier is perhaps my favorite feature in Swift 3. Let’s
> not throw stuff away because it adds extra characters to one programming
> style.
>
> Finally, SE-0025 establishes clear motivation for the scoped access
> modifier:
>
> > Currently, the only reliable way to hide implementation details of a
> class is to put the code in a separate file and mark it as private. This is
> not ideal for the following reasons:
>
> > It is not clear whether the implementation details are meant to be
> completely hidden or can be shared with some related code without the
> danger of misusing the APIs marked as private. If a file already has
> multiple classes, it is not clear if a particular API is meant to be hidden
> completely or can be shared with the other classes.
>
> > It forces a one class per file structure, which is very limiting.
> Putting related APIs and/or related implementations in the same file helps
> ensure consistency and reduces the time to find a particular API or
> implementation. This does not mean that the classes in the same file need
> to share otherwise hidden APIs, but there is no way to express such
> sharability with the current access levels.
>
> As far as I can see, the proposal does not actually address or acknowledge
> these problems at all, but cheerfully returns us to them. It would be a
> mistake to deprecate this feature without examining at all why we
> introduced it. And realistically we need new solutions to those problems
> before removing the existing one.
>
> Drew
>
> On March 20, 2017 at 6:54:55 PM, Douglas Gregor (dgregor at 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 Reviews are an important part
> of the Swift evolution process. All reviews should be sent to the
> swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution or, if you would
> like to keep your feedback private, directly to the review manager. When
> replying, please try to keep the proposal link at the top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0159-fix-private-access-levels.md Reply text Other replies What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> What is your evaluation of the proposal? Is the problem being addressed
> significant enough to warrant a change to Swift? Does this proposal fit
> well with the feel and direction of Swift? If you have used other languages
> or libraries with a similar feature, how do you feel that this proposal
> compares to those? How much effort did you put into your review? A glance,
> a quick reading, or an in-depth study? More information about the Swift
> evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md Thank you,
>
> -Doug
>
> Review Manager
> ------------------------------
>
> swift-evolution-announce mailing list swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
--
*Pranshu Goyal*
*iOS Developer*
*tlkn*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/ee5cfa7c/attachment.html>
More information about the swift-evolution
mailing list