> On Mar 26, 2017, at 8:30 AM, Matthew Johnson <[email protected]> wrote: > On Mar 26, 2017, at 4:13 AM, John McCall via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >>> On Mar 26, 2017, at 4:27 AM, Goffredo Marocchi <[email protected] >>> <mailto:[email protected]>> wrote: >>> On 26 Mar 2017, at 06:54, John McCall via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> Yes, it would change my opinion of it. I wouldn't become a strong >>>>> supporter because I don't see any value in it, but a rigorous proof that >>>>> this proposal could not possibly introduce regressions to any existing >>>>> codebases would change my opinion from "strongly against" to "doesn't >>>>> matter to me, I'll stop arguing against it and go get my real work done". >>>>> >>>> Speaking just for myself, this was a key part of why I was attracted to >>>> this proposal: it seemed to me to be extremely unlikely to cause >>>> regressions in behavior. Even without any special behavior in the >>>> migrator, code will mostly work exactly as before: things that would have >>>> been invalid before will become valid, but not the other way around. The >>>> exception is that old-private declarations from scopes in the same file >>>> can now be found by lookups in different scopes (but still only within the >>>> same file). It should be quite straightforward for the migrator to detect >>>> when this has happened and report it as something for the programmer to >>>> look at. The proposal causes a small regression in functionality, in that >>>> there's no longer any way to protect scopes from accesses within the file, >>>> but (1) it's okay for Swift to be opinionated about file size and (2) it >>>> seems to me that a workable sub-module proposal should solve that more >>>> elegantly while simultaneously addressing the concerns of the people who >>>> dislike acknowledging the existence of files. >>> >>> The opinionated flag sometimes, like being Swifty, is being used to swath >>> away disagreement, but opinions should be reasonable and pragmatic too... >>> opinionated as "you will code this way and you will like it" seems hardly >>> ideal too if abused constantly. Programming is a creative endeavour too. >>> >>> Also, removing a feature that is used and is useful because "maybe" a year >>> or more away there could be a feature that may address the concerns of the >>> people we are stripping away the current feature from seems quite harsh and >>> unfriendly at best... not very logical either. >> >> Scoped-private is not some awesomely expressive feature. It's an access >> restriction. The "opinion" I'm talking about hardly prevents you from >> coding however you like. It's just this: organizing your code into smaller, >> more self-contained components separated by file is good practice anyway, >> and when you do that, Swift will let you enforce that each component is >> properly encapsulated. > > This does not address the case where we have a small helper type that is only > 10s of lines long, is not visible outside the file, and encapsulates an > important part of the implementation using scoped private. The whole file is > usually only a couple hundred lines. This is not an excessively long file > and already contains a single component that is presented to the rest of the > program.
I acknowledge that this case exists, but by definition, it's a tiny amount of code being "protected" from an almost equally tiny amount of code. Access control is primarily communicative. A person who adds unwanted uses of a private property can also just as easily change the access restriction. The point of private access control is to communicate that you've thought about it and that people should think before assuming that it's okay to use something. When you're talking about about tiny amounts of code, that level of communication really is good enough. It has to be, because access control is never going to be sufficiently expressive to express constraints like "this method can only be called from this other method" — we actively would not want to encourage programmers to engage in that level of pedantry, because some of them will, and they'll make themselves miserable and accomplish nothing of value, and they'll blame Swift (correctly) for implying that it was important. > Some designs of submodules might allow us to properly encapsulate everything > but if that requires us to put a small helper type in a separate file that > would be a very unfortunate and inflexible constraint on how we are able to > organize our code. > > I don't want encapsulation concerns dictating how I physically organize my > code. That is significant and unnecessary complexity if you ask me. It > forces a tradeoff between desired physical organization and desired > encapsulation. We should not force users to make this tradeoff. See, you say this, and you're apparently talking talking about the burdens of maintaining a 200-line file. Someone else says it, and their files are 10,000 lines long. I'm going to be opinionated and say that, no, physical organization is inherently linked to encapsulation because of the implicit outer scope of the file, and that if you care about encapsulation, you should also be organizing your code to minimize that outer scope, which will also make it trivial to understand how a private declaration is used and recognize in code reviews for changes that touch that file that they're accessing something they shouldn't. John. > >> >> John. >> >>> >>>> >>>> John. >>>>> -Carl >>>>> >>>>> <graycol.gif>Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your >>>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 >>>>> <Carl.Br >>>>> >>>>> From: Xiaodi Wu <[email protected] <mailto:[email protected]>> >>>>> To: Carl Brown1/US/IBM@IBM >>>>> Cc: Drew Crawford <[email protected] >>>>> <mailto:[email protected]>>, Jonathan Hull <[email protected] >>>>> <mailto:[email protected]>>, swift-evolution <[email protected] >>>>> <mailto:[email protected]>> >>>>> Date: 03/25/2017 12:33 AM >>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access >>>>> Levels >>>>> >>>>> >>>>> >>>>> >>>>> Would it change your opinion on the proposal? >>>>> >>>>> >>>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> I would very much like to see your proof that the resultant code is >>>>> unchanged in an arbitrary codebase. >>>>> >>>>> -Carl >>>>> >>>>> <graycol.gif>Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 >>>>> at 11:55 PM, Carl Brown1 <[email protected] >>>>> <mailto:[email protected]>> wrote: > Maybe this is the core >>>>> >>>>> From: Xiaodi Wu <[email protected] <mailto:[email protected]>> >>>>> To: Carl Brown1/US/IBM@IBM >>>>> Cc: Drew Crawford <[email protected] >>>>> <mailto:[email protected]>>, Jonathan Hull <[email protected] >>>>> <mailto:[email protected]>>, swift-evolution <[email protected] >>>>> <mailto:[email protected]>> >>>>> Date: 03/25/2017 12:01 AM >>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels >>>>> >>>>> >>>>> >>>>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> My point is that, in rolling back the specific portion of SE-0025, >>>>> case-sensitive find-and-replace will be the trickiest thing in most >>>>> codebases, save those that result in invalid redeclarations. The behavior >>>>> of the resultant code is, unless I'm mistaken, provably unchanged. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
