On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan <[email protected]> wrote:
> > On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky < > [email protected]> wrote: > > Daniel, I would be interested to hear what, exactly, are the benefits your > project has realized from the new “private” compared to the old “private” > (which is now called “fileprivate”). > > There's no amazing insight here. The benefit is more granular control. The > more people work on a project, the more useful this becomes. > More granular control *within a single file*. That is where I have a hard time imagining the benefits, and thus am asking for details. If there are multiple types within a single file, it is usually because they need to share implementation details. The only things that I see which scope-based access (the new “private”) brings to the table are: • Scope-private members from other parts of the file are unavailable (and thus don’t show in autocomplete). • Different extensions of a type can have scope-private members with the same name as each other. The former seems negligible, because you are working *within the same file*. The API that a type vends within its own file is hardly worth optimizing for. And the latter I would say is an anti-feature. Using multiple different members with the same name in extensions just makes it harder to rearrange the implementation, because those scope-private members will collide if moved into the same extension. So I *really* don’t see the benefits. Yes, I understand that there is now more granular control over access within a single file. I am asking for examples of how that additional granularity provides *benefits*. On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan <[email protected]> wrote: > You might as well ask "why not make everything public" if private and > fileprivate makes no difference to you. > That is not a fair assertion at all. The API which a type vends to other files within its module, and to clients outside its module, are significant parts of a quality and maintainable design. I do not think the API which a type vends *within its own file* warrants such lofty prioritization. > On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan <[email protected]> wrote: > >> >> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky < >> [email protected]> wrote: >> > As I see it, two significant drawbacks of the new “private” are increased > complexity in the access control model, and encumbrance of the old > “private” with the unwieldy moniker “fileprivate”. > > The first drawback is a truism: every language addition of feature makes > it more complex. > You can’t just write off the complexity cost like that. The new scope-based “private” access level brings *substantial* complexity, to both the implementation and the mental programming model. It creates *unutterable* access levels, where a scope can see a member of another scope, but cannot create its own member with the same access level. On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan <[email protected]> wrote: > > So we need to measure the benefit with other costs, which brings us to > your second "drawback". I'm having a hard time understanding it. Is it too > hard to type? If so, as an Objective-C survivor I disagree. The experience > of reading code is harder and therefore more important than that of > authoring code. "fileprivate" was chosen over many other alternatives > because it's obvious to the reader. A shorter but equally obvious name > would have been nice. But "unwieldy" is not enough reason to justify such > source-breaking change at the moment. > Right, “unwieldy” is not enough to justify a source-breaking change. I entirely agree. It is the *complexity* of the current model that would justify the source-breaking change, if it does not have real benefits which stand on their own and outweigh the costs. What unwieldiness *does* justify is a non-breaking change, such as introducing “privy” (or something else) as a synonym for “fileprivate”, then eventually deprecating and removing the latter. • • • I will also note that the principal practical effect of SE-0025 was “Replace a small number of occurrences of ‘private’ with ‘fileprivate’.” That is essentially all it did to source code. It brought a significant increase to the complexity of the access control model, in order to make a few member declarations lengthier and more awkward. Maybe there are other benefits, but I have not seen them. • • • Let me reiterate my stance: if the new scope-based “private” has benefits which outweigh its complexity cost, then we should keep it. Otherwise we should get rid of scope-based access control and reinstate the old file-based “private”. Furthermore, we should rename “fileprivate” to something shorter and less awkward, which will play nice with submodules. If “private” is off the table then I propose “privy”, though I welcome other suggestions. Nevin If the new “private” has brought real benefits sufficient to outweigh its > complexity cost then I think it should stay, and if not it should go. Thus > I am curious to see what benefits it has in practice. > > • • • > > Regardless of whether the new “private” is pulling its weight, I believe > we should find a shorter name for “fileprivate”. > > And I think Xiaodi has the right idea: whensoever in the future we decide > to introduce submodules, it would be best if they subsumed the file scope. > In essence, a submodule would be the mechanism for parceling out code which > currently must reside in a single file (because it relies on “fileprivate” > which is the old “private”). > > That way a submodule could comprise several interrelated pieces which need > to share privy details, while preserving their natural separation into > distinct files. So it makes sense that we should find a replacement for > “fileprivate” which is copacetic to submodules. > > Actually, now that I write it down, I wonder if perhaps “privy” might work > as a keyword. It is short, it means “being party to shared secret > knowledge”, and its spelling conveys a sense of “private-ish”. > > The other ideas I’ve come up with have shortcomings, such as “local” which > has a pre-existing incompatible meaning in programming (otherwise it would > be great), or “folio” which is not an adjective (and also isn’t ideal for > the single-file case). > > But “privy” just might work. > > Nevin > > > On Thu, Oct 13, 2016 at 10:44 PM, Daniel Duan via swift-evolution < > [email protected]> wrote: > >> I question the practicality of "use private heavily simply because I >> don’t want the burden of mixing private and fileprivate". In our experience >> in converting a very mature Swift application, we had no choice but to use >> both because we wanted private as much as possible but that's too >> restrictive in some cases. The granularity private and fileprivate provide >> is definitey a welcome change. >> >> Daniel Duan >> Sent from my iPhone >> >> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution < >> [email protected]> wrote: >> >> >> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution < >> [email protected]> wrote: >> >> >> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution < >> [email protected]> a écrit : >> >> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution < >> [email protected]> wrote: >> >> I actually consider it very lucky that most of our changes so far have >> been fairly non-controversial. Everybody has a different idea of what would >> make Swift a better language, and all of us well-meaning. But when those >> ideas conflict, some group is going to end up unhappy. I'm actually very >> glad that (a) we haven't had too many of these cases, and (b) even when we >> have, people have been able to accept it and move on to contributing to the >> next issue. >> >> >> Strong agreement here as well. This proposal has been litigated numerous >> times already, and the bar for source-breaking changes is much higher now. >> To effectively re-open the discussion would require a proposal that >> significant changes the model with a lot of evidence that such a new model >> is a drastic improvement over what we have now. “Back out SE-0025” is not a >> viable option now. >> >> - Doug >> >> >> Not really. This proposal could be backed out without source-breaking >> changes by treating private as a synonym for fileprivate and we’d have >> Swift 2 behavior without breaking source. If the core team doesn’t want to >> consider that then we can just move on and live with it. >> >> >> Not speaking for the core team, just MHO: >> >> I agree with Russ here, and with others who have said upthread that the >> “thing that has changed” is that we are starting to get usage experience >> with fileprivate vs private. I think we all understand the value of having >> fewer access control levels, and so if “private” isn’t conceptually pulling >> its weight, then it is reasonable to consider phasing it out. >> >> That said, there is no specific rush to have this discussion, and I think >> it is reasonable to put a pretty high burden of proof on someone who wants >> to drive such a proposal. For example, if we had the discussion in the >> spring timeframe, we should have a pretty large body of Swift 3 code >> readily at hand (e.g. SwiftPM packages and other various github repos). >> >> Given that, it should be easy enough to see how widely private is >> actually being used in practice. If it is very rare, then the argument to >> ditch it (make it a synonym for fileprivate, and eventually phasing out >> fileprivate) is strong. If lots of people are using private and only some >> are using fileprivate, then the discussion is quite different. >> >> -Chris >> >> >> I don’t think monitoring the usage of private vs fileprivate is fair. By >> default, people will use private until they encounter visibility issues and >> discover they need to change to fileprivate. So private will probably being >> use far more than fileprivate. >> Nonetheless it does not mean people chosen private because it effectively >> reduce the visibility to the class scope, but just because it is easier to >> discover and to type than fileprivate and fit in many cases. >> >> I tend to write class will all ivars private by default (as it is a >> sensible default), and then, when I start to write extensions and other >> parts, I have to switch to fileprivate for a bunch of ivars. It create an >> inconsistent mess in my ivars declaration as it is difficult to know if an >> ivar is private because I has to be, or because I didn’t encounter a case >> that need it to be fileprivate instead. >> >> Honestly, I don’t see any value in the introduction of fileprivate. >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> I also agree that monitoring the usage of private vs fileprivate is not >> fair. I now use private heavily simply because I don’t want the burden of >> mixing private and fileprivate (and find the name of fileprivate slightly >> verbose/ugly). But that does not mean I would vote for keeping private. I >> would still vote for going back to Swift 2 behaviour. But I agree that we >> can wait until the summer to look at this again. >> >> _______________________________________________ >> 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
