Very good graphic. But it reinforces my opinion that it's currently more messy/complicated than I should be. It looks like an over-designed or designed-by-comitee model. I understand that private is useful, but not useful enough to warrant the increased complexity. My 2 cents.
> On 13 Feb 2017, at 15:25, Adrian Zubarev via swift-evolution > <swift-evolution@swift.org> wrote: > > I actually made a small visual of how open vs. public should work constantly > on twitter: https://twitter.com/DevAndArtist/status/829688528216924160 > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 13. Februar 2017 um 15:20:10, Matthew Johnson via swift-evolution > (swift-evolution@swift.org) schrieb: > >> >> >> Sent from my iPad >> >> > On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution >> > <swift-evolution@swift.org> wrote: >> > >> > >> >> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution >> >> <swift-evolution@swift.org> wrote: >> >> >> >> I think I we can live with the original three: public, internal, and >> >> private >> >> >> >> Where public is visible to all, >> >> Internal is visible to all within the module, and private is visible only >> >> to the class and the same file. >> >> >> >> We can still fulfill the same roles that the current five fill. >> >> >> >> Open can become public again. >> >> Public can become final public >> >> This is incorrect. The way `public` behaves today is very different than >> `final public`. Today it only restricts clients of a library from >> subclassing the class. `final public` also prevents the library itself from >> doing this not only in future versions, but also in the current version. >> This is very useful behavior that is not available if we adopt your >> suggestion. >> >> >> Internal remains the same >> >> Fileprivate assimilates into private >> >> >> >> Make access control simple again! >> > >> > Agree. >> > >> > To me this discussion exemplifies the “square peg in a round hole” problem. >> > None of these (fileprivate & open) keywords add information to a source >> > code. They do add noise however. >> > >> > The difference between fileprivate and private is only of importance to a >> > group development effort. And then it is used for internal communication >> > within that group, never to the outside world. In a way “private” tells >> > other group members that they should ask the original developer why he >> > choose private instead of fileprivate. (And more than often be told “just >> > change it”) >> > This is something that would be better solved by comments imo. >> >> This is not true at all. I have found the distinction useful both in >> personal projects and in a team environment. >> >> > >> > Open vs public is less obvious as there seems to be a use case for this. >> > However in the end it only “forces” an API user to wrap the “public” >> > interface so he can then use it again as “open”. >> > Hence it does not solve a design problem, it only leads to a cumbersome >> > interface. >> >> Composition is often a better approach than inheritance. Allowing a library >> to expose classes publicly is very valuable. It allows them the ability to >> design classes that are not intended to be subclasses and have that intent >> verified by the compiler. Supporting subclassing correctly is difficult and >> not always appropriate. >> >> > >> > >> > Now, if we really want to add information to the source code, then we >> > would do away with the restriction approach entirely and adopt an access >> > list approach. I.e. it would be possible to specify for each interface >> > element which other module/file has access to it. >> >> A long list of access specifications does not lend itself to clarity or >> conciseness. While it is more specific, it is also far more difficult to >> comprehend. Swift strikes a pretty good balance of control, clarity of >> intent and conciseness IMO, but ultimately this is a judgement call. >> >> > >> > Regards, >> > Rien >> > >> > Site: http://balancingrock.nl >> > Blog: http://swiftrien.blogspot.com >> > Github: http://github.com/Balancingrock >> > Project: http://swiftfire.nl >> >> >> > >> >> On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via swift-evolution >> >> <swift-evolution@swift.org> wrote: >> >> On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer <dplanit...@q.com> >> >> wrote: >> >> I know that private was scoped to files before Swift 3. >> >> >> >> Fileprivate should obviously be removed because it is, like I said >> >> previously, just a poor man’s package access level. Yes, private was >> >> scoped to a file before Swift 3, but at least there wasn’t two kinds of >> >> private for a single file. Also scoping private to a file makes sense in >> >> Swift because it plays well with the ability to organize the >> >> implementation of a type inside of a file into the base type and a number >> >> of extensions. I now have to use fileprivate in Swift 3 to pull this off >> >> while there isn’t a requirement for a separate private access level. The >> >> fileprivate / private distinction also needlessly gets in the way when >> >> you want to refactor an existing type implementation into base type + >> >> extensions, all living in the same file. >> >> >> >> Anyway, I don’t see a good reason why we should end up with this, once >> >> sub-modules exist: >> >> >> >> open, public, module, fileprivate, private >> >> >> >> when we can live with this: >> >> >> >> open, public, module, private >> >> >> >> and we’re not losing anything that would be significant compared to the >> >> alternative scenario. >> >> >> >> Well, there's also internal: open, public, internal, (submodule, however >> >> it is named), private. >> >> >> >> The question being discussed here is whether private should have the old >> >> or new meaning. I tend to agree with others that the new `private` >> >> doesn't add much. Modules are a different conversation. >> >> >> >> Regards, >> >> >> >> Dietmar Planitzer >> >> >> >>> On Feb 12, 2017, at 18:16, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >>> >> >>> What was added in Swift 3 was `private`; the old `private` was renamed >> >>> `fileprivate` with no change in behavior. Certainly, submodules are a >> >>> big topic that deserves careful consideration. But the question being >> >>> discussed here is about rolling back the change that was implemented in >> >>> Swift 3 by removing `private` and restoring `fileprivate` to its old >> >>> name. >> >>> >> >>> >> >>> On Sun, Feb 12, 2017 at 8:08 PM, Dietmar Planitzer via swift-evolution >> >>> <swift-evolution@swift.org> wrote: >> >>> Fileprivate is a feature that should not have been added to Swift 3 >> >>> because it is in the end just a needlessly limited version of the Java >> >>> package access level. Fileprivate forces me to put all types which are >> >>> related on an implementation level into the same file while Java >> >>> packages allow me to put each type implementation into a separate file. >> >>> The only thing that Java requires is that all files which are part of >> >>> the same package are tagged with the same package id. Java’s package >> >>> access level is more powerful than fileprivate because it gives me more >> >>> freedom in how I want to organize my code while still making sure that >> >>> code in sibling and parent packages can not access symbols inside my >> >>> package which form part of the implementation details of my package. >> >>> >> >>> The first thing that needs to happen before any more access levels are >> >>> added is that a concept of sub-modules is added to Swift along the lines >> >>> of: >> >>> >> >>> 1) modules can be organized into a tree with one module as the root. >> >>> >> >>> 2) all modules which are nodes in the same module tree form a single >> >>> resilience domain. >> >>> >> >>> IMO, the sub-module stuff should be designed similar if not the same way >> >>> as Java packages because there are already lots and lots of SDEs who >> >>> know how Java packages work, and Java packages are well understood, >> >>> simple and straight-forward in their mechanics. >> >>> >> >>> Once sub-modules are in place, it makes sense to revisit the access >> >>> level topic. Eg in order to add a “module” access level that represents >> >>> the scope of a module. So “module” could then do what file private can >> >>> do today plus more. But we should stop trying to add more access level >> >>> to the language until then. We also need to look much more at the bigger >> >>> picture of things instead of getting too much hung up on a single >> >>> component of a larger mechanism, when it is that larger mechanism that >> >>> is primarily interesting and relevant. >> >>> >> >>> >> >>> >> >>> Regards, >> >>> >> >>> Dietmar Planitzer >> >>> >> >>>> On Feb 12, 2017, at 16:16, Zach Waldowski via swift-evolution >> >>>> <swift-evolution@swift.org> wrote: >> >>>> >> >>>> I vehemently agree on these points. New-private and fileprivate "[add] >> >>>> more information" to a file the same way requiring `self.` and other >> >>>> sorts of visual noise that Swift normally eschews. >> >>>> >> >>>> I wish for the Swift community to be introspective enough to count both >> >>>> its successes and failures. SE-0025 was a botched addition to the >> >>>> language. That the migrator did such a bad job is evidence of its poor >> >>>> overall consideration. Adding a fix-it strikes me as the compiler >> >>>> waggling its finger at me for code that would've been perfectly fine in >> >>>> the past, something that it is not at all true with the "let" fix it; >> >>>> accidental mutation has been discussed a ton by the larger programming >> >>>> community, not-so-much for obscure access control mechanics. >> >>>> >> >>>> It's perplexing that fileprivate advocates continue to stand on mostly >> >>>> theoretical benefits about new-private. I feel nothing for the >> >>>> mathematical purity about the types in a file. In practice, I can with >> >>>> much experience now how awful it is. There has been no end to the >> >>>> confusion its introduction has inflicted upon my team(s), people new to >> >>>> the language, and people revisiting the language: >> >>>> >> >>>> - My teams and coworkers are less effective at code review from >> >>>> constant litigation about access control. "'Did this need to change?' / >> >>>> 'No, it was just the migrator.'" has become a disturbingly common >> >>>> refrain. >> >>>> >> >>>> - New users are just struggling to figure out where to put the curly >> >>>> braces in the first place. Having to make them check and re-check where >> >>>> things go in a file, or just tell them to use this clunky >> >>>> get-out-of-jail-free keyword, feels like visiting a special kind of >> >>>> Pythonic hell on a language I otherwise love and love to teach. >> >>>> >> >>>> - People returning to the language feel (and often say - just look at >> >>>> Twitter) Swift has a lot of syntax, and are frustrated that the >> >>>> addition of a new keyword was burned on adding something that amounts >> >>>> to mostly a stylistic opinion. >> >>>> >> >>>> All the best, >> >>>> Zachary Waldowski >> >>>> z...@waldowski.me >> >>>> >> >>>>> On Sun, Feb 12, 2017, at 04:45 PM, Xiaodi Wu via swift-evolution wrote: >> >>>>> On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson >> >>>>> <matt...@anandabits.com> wrote: >> >>>>> >> >>>>> >> >>>>>> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution >> >>>>>> <swift-evolution@swift.org> wrote: >> >>>>>> >> >>>>>> _Potentially_ meaningful, certainly. But what I'm hearing is that it >> >>>>>> isn't actually meaningful. Here's why: >> >>>>>> >> >>>>>> If I see `fileprivate` and can understand that to mean "gee, the >> >>>>>> author _designed_ this member to be visible elsewhere inside the >> >>>>>> file," then it's actually meaningful. OTOH, if I see `fileprivate` >> >>>>>> and can only deduce "gee, the author mashed some button in his or her >> >>>>>> IDE," then it's not really telling me anything. >> >>>>> >> >>>>> >> >>>>> You’re looking at it backward. It’s when you see `private` and can >> >>>>> deduce “this member is only visible inside it’s declaring scope” that >> >>>>> can be really helpful. *This* is what matters. >> >>>>> >> >>>>> In what ways can that information help you? >> >>>>> >> >>>>> >> >>>>>> What you've said above, as I understand it, is that it's not >> >>>>>> currently meaningful to see `fileprivate` because the migrator is >> >>>>>> writing it and not the author. The improved approach you proposed is >> >>>>>> the additional warning. In that case, the compiler will help to >> >>>>>> ensure that when I see `fileprivate`, at least I know it's necessary. >> >>>>>> But that's only telling me a fact (this member is accessed at least >> >>>>>> once outside the private scope), but it's still machine-based >> >>>>>> bookkeeping, not authorial intent. >> >>>>> >> >>>>> >> >>>>> The important thing is that this machine-based bookkeeping results in >> >>>>> a proof about the code. This facilitates reasoning about the code. You >> >>>>> can make an argument that this proof is not important enough to >> >>>>> matter, but you must admit that this is a real concrete gain in >> >>>>> information that is immediately available to a reader of the code >> >>>>> (after they know that it compiles). Personally, I find this proof to >> >>>>> be valuable. >> >>>>> >> >>>>> Comparison has been made to `let` and `var`. In that case, whether a >> >>>>> variable is mutated can be non-trivial to deduce (as Swift has no >> >>>>> uniform scheme for distinguishing mutating from non-mutating >> >>>>> functions; the ed/ing rule has many exceptions). By contrast, here, I >> >>>>> don't see any gain in information. You can literally *see* where the >> >>>>> (file)private member is accessed, and when a file gets too long, even >> >>>>> a simple text editor can do a decent enough find. >> >>>>> >> >>>>> If you're right that the real value is that seeing `private` helps you >> >>>>> reason about the code, then that value must be commensurate to how >> >>>>> often we see Swift users amending the migrator to take advantage of >> >>>>> it. For me, the compelling evidence that Swift users don't find this >> >>>>> proof to be valuable is that, by examination of Swift 3 code, Swift >> >>>>> users haven't bothered. If we add a new fix-it to force them to, then >> >>>>> of course they'll mash the buttons, but it's pretty much declaring >> >>>>> that they are wrong not to care about what it seems they do not care >> >>>>> at present. >> >>>>> >> >>>>>> On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sa...@nondot.org> >> >>>>>> wrote: >> >>>>>> I don't fully agree: you are right that that is the case when writing >> >>>>>> code. However, when reading/maintaining code, the distinction is >> >>>>>> meaningful and potentially important. >> >>>>>> >> >>>>>> -Chris >> >>>>>> >> >>>>>> >> >>>>>>> On Feb 12, 2017, at 12:02 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >>>>>>> If the overwhelming use case is that developers should pick one over >> >>>>>>> the other primarily because it looks nicer, then blindly click the >> >>>>>>> fix-it when things stop working, then the distinction between >> >>>>>>> private and fileprivate is pretty clearly a mere nuisance that >> >>>>>>> doesn't carry its own weight. >> >>>>>>>> On Sun, Feb 12, 2017 at 13:33 Jean-Daniel via swift-evolution >> >>>>>>>> <swift-evolution@swift.org> wrote: >> >>>>>>>> Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution >> >>>>>>>> <swift-evolution@swift.org> a écrit : >> >>>>>>>> >> >>>>>>>> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution >> >>>>>>>> <swift-evolution@swift.org> wrote: >> >>>>>>>>> Final >> >>>>>>>>> Can someone tell me what is the use of 'final' now that we have >> >>>>>>>>> 'public' default to disallowing subclassing in importing modules? >> >>>>>>>>> I know that 'final' has the added constraint of disallowing >> >>>>>>>>> subclassing in the same module, but how useful is that? Does it >> >>>>>>>>> hold its weight? Would we add it now if it did not exist? >> >>>>>>>> >> >>>>>>>> As Matthew says, this is still important. >> >>>>>>>> >> >>>>>>>>> Lazy >> >>>>>>>>> This one is clearer: if Joe Groff's property behaviors proposal >> >>>>>>>>> from last year is brought forward again, lazy can be demoted from >> >>>>>>>>> a language keyword to a Standard Library property behavior. If Joe >> >>>>>>>>> or anybody from the core team sees this: do we have any luck of >> >>>>>>>>> having this awesome feature we discussed/designed/implemented in >> >>>>>>>>> the Swift 4 timeframe? >> >>>>>>>> >> >>>>>>>> Sadly, there is no chance to get property behaviors into Swift 4. >> >>>>>>>> Hopefully Swift 5, but it’s impossible to say right now. >> >>>>>>>> >> >>>>>>>>> Fileprivate >> >>>>>>>>> >> >>>>>>>>> I started the discussion early during the Swift 4 timeframe that I >> >>>>>>>>> regret the change in Swift 3 which introduced a scoped private >> >>>>>>>>> keyword. For me, it's not worth the increase in complexity in >> >>>>>>>>> access modifiers. I was very happy with the file-scope of Swift >> >>>>>>>>> pre-3. When discussing that, Chris Latner mentioned we'd have to >> >>>>>>>>> wait for Phase 2 to re-discuss it and also show proof that people >> >>>>>>>>> mostly used 'fileprivate' and not the new 'private' modifier as >> >>>>>>>>> proof if we want the proposal to have any weight. Does anybody >> >>>>>>>>> have a good idea for compiling stats from GitHub on this subject? >> >>>>>>>>> First of all, I've always found the GitHub Search quite bad and >> >>>>>>>>> don't know how much it can be trusted. Secondly, because 'private' >> >>>>>>>>> in Swift 2 and 3 have different meanings, a simple textual search >> >>>>>>>>> might get us wrong results if we don't find a way to filter on >> >>>>>>>>> Swift 3 code. >> >>>>>>>> >> >>>>>>>> I would still like to re-evaluate fileprivate based on information >> >>>>>>>> in the field. The theory of the SE-0025 >> >>>>>>>> (https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md) >> >>>>>>>> was that the fileprivate keyword would be used infrequently: this >> >>>>>>>> means that it would uglify very little code and when it occurred, >> >>>>>>>> it would carry meaning and significance. >> >>>>>>> >> >>>>>>> Infrequent use and significance are orthogonal. >> >>>>>>> I still think developers would declare all ivars private (this is >> >>>>>>> less ugly and shorter), and then will happily convert them to >> >>>>>>> fileprivate each time the compiler will tell them they are not >> >>>>>>> accessible somewhere else in the file. >> >>>>>>> As the code that try to access that ivar is in the same file anyway, >> >>>>>>> it has full knowledge of the implementation details and there is no >> >>>>>>> good reason it shouldn’t be able to access the ivar when needed. >> >>>>>>> >> >>>>>>>> We have a problem with evaluating that theory though: the Swift >> >>>>>>>> 2->3 migrator mechanically changed all instances of private into >> >>>>>>>> fileprivate. This uglified a ton of code unnecessarily and (even >> >>>>>>>> worse) lead programmers to think they should use fileprivate >> >>>>>>>> everywhere. Because of this, it is hard to look at a random Swift 3 >> >>>>>>>> codebase and determine whether SE-0025 is working out as intended. >> >>>>>>>> >> >>>>>>>> The best way out of this that I can think of is to add a *warning* >> >>>>>>>> to the Swift 3.1 or 4 compiler which detects uses of fileprivate >> >>>>>>>> that can be tightened to “private” and provide a fixit to do the >> >>>>>>>> change. This would be similar to how we suggest changing ‘var’ into >> >>>>>>>> ‘let’ where possible. Over time, this would have the effect of >> >>>>>>>> getting us back to the world we intended in SE-0025. >> >>>>>>>> >> >>>>>>>> -Chris >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> swift-evolution mailing list >> >>>>>>>> swift-evolution@swift.org >> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>>>>>> _______________________________________________ >> >>>>>>> swift-evolution mailing list >> >>>>>>> swift-evolution@swift.org >> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> swift-evolution mailing list >> >>>>>> swift-evolution@swift.org >> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>>>> _______________________________________________ >> >>>>> swift-evolution mailing list >> >>>>> swift-evolution@swift.org >> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>>> >> >>>> _______________________________________________ >> >>>> swift-evolution mailing list >> >>>> swift-evolution@swift.org >> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>> >> >>> _______________________________________________ >> >>> swift-evolution mailing list >> >>> swift-evolution@swift.org >> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>> >> >> >> >> _______________________________________________ >> >> swift-evolution mailing list >> >> swift-evolution@swift.org >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> >> swift-evolution mailing list >> >> swift-evolution@swift.org >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > swift-evolution@swift.org >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
