> • What is your evaluation of the proposal? Positive.
I could not stress enough how the attitude behind such a proposal is *positive*. > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. private / fileprivate had a tremendous design issue: developers would jump from private to fileprivate just to shut up the compiler. Now this won't happen unless an actual design decision. > • Does this proposal fit well with the feel and direction of Swift? Yes. > • If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? Reasonably well. > • How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? Have pity. It's very difficult to follow this topic that has generated thousands of messages. I vote +1 because the proposal looks reasonable, balanced, and focused on regular developers. <rant>I wish people who insists on splitting hairs about access control would give us a break already.</rant> Gwendal Roué > Le 11 avr. 2017 à 13:00, David Hart via swift-evolution > <[email protected]> a écrit : > > > On 11 Apr 2017, at 08:48, Tino Heth via swift-evolution > <[email protected]> wrote: > >> -1 (strong) >> >> I think I've read all messages and haven't much to add — so just to sum up >> my concerns in order: >> — It makes access control more complicated >> For me, it's not about the complexity itself (it's not terrible huge, after >> all), but I believe in the beauty of simplicity, which is already quite >> flawed. >> — It adds no power to the language >> The proposal solves no real problem, but rather encourages a certain style >> of programming, which is quite popular among authors of styleguides, but has >> no clear net gain. > > While your other points are defendable, I have to disagree here. It does > bring value to a population of developers (me included) for whom that style > of programming adds a lot of readability. It's part of style guides for a > reason. > >> — It diminishes the need for fileprivate without making it redundant >> It would be nice to get rid of an access level, but having four common ones >> and fileprivate as an exotic outlier doesn't feel right for me. > > Doesn't the argument of progressive disclosure sway you here? open is already > an outlier that only library authors will play with, and that's a good thing. > It reduces the number of access level truly useful on a day to day basis, > while leaving the others for more narrow purposes. > >> — It is a mockery for SE-0025 >> I never liked "new private", but it was decided that this sort of >> encapsulation is important enough to justify 33% increase in the number of >> access levels, so I don't like to see this watered down >> — It is a breaking change >> For me personally, that doesn't really count as an argument on its own, and >> I would gladly take the inconvenience of incompatibility in exchange for a >> tiny improvement of the language; but in combination with the other points, >> it increases opposition. >> >> I spend some time thinking about nested extensions (which would achieve the >> goal of this proposal naturally) and think that SE-0169 would lead to some >> questionable possibilities of short-circuiting access control: >> >> class Outer { >> private class Inner { >> private var x = 0 >> } >> } >> >> /* >> . >> . >> . >> */ >> >> extension Outer.Inner { >> public func f() { >> print(x) >> } >> } >> >> As I read the proposal, there is no doubt that this would be allowed — but >> without that detailed information, I'm not sure if anybody would expect that >> two levels of private still is not enough to keep something secret… >> >> - Tino >> _______________________________________________ >> 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
