[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull]

> On Mar 24, 2017, at 6:07 AM, Goffredo Marocchi <panajev at gmail.com> wrote:
> On Fri, Mar 24, 2017 at 9:59 AM, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> Several people have asked:  What is the harm it causes?
> 
> I would like to provide a (hopefully) clear answer to that.
> 
> There are a couple of problems with the design which are causing Cognitive Dissonance:
> 
> 1) Private & fileprivate require very different mental models to operate them
> 2) They are named very similarly to each other
> 3) There is a third concept of “private to the type” which requires a third mental model, but is spelled the same way in other languages 
> 
> Any one of these would cause confusion.  All of them together mean that even those of us who understand how they work are bothered by them on a subconscious level (similar to how misaligned graphics will give everyone a subconscious feeling that a graphic design is “off” even if they can’t discern why consciously).  Even many of those who are arguing to keep private have argued to rename things or to make it work in a more type-based way by extending visibility to extensions.  I don’t think anyone is denying there is a problem here with the status quo.
> 
> There is a general rule in design that things that look similar (or in this case are named similarly) need to behave similarly to avoid causing confusion (and conversely things that behave differently *need* to look different).
> 
> **This is not something that will go away simply by learning the behavior.  It will continue to be a rough spot in the language that causes discomfort until the underlying design issue is fixed.**
> 
> The ideal solution here would be to choose a single model and make everything coherent under that.  We choose either file-based, scope-based, or type-based access control and unify under that.
> 
> Why would this be the ideal solution? I tend to disagree and I do not think there is real agreement or even anything approaching consensus that it would be ideal... it feels quite restrictive.


My goal was to explain the cognitive psychology of why this is an issue so we can work together on solving the underlying causes (as opposed to making random changes until something feels right)

As I said above, the names are not the only issue causing the problem.  It is how the concepts interact in your brain.  They are locally consistent, but globally inconsistent. Basically, you look at one of them, and it makes sense, but when you try to consider both of them at once, it doesn’t quite fit.  The fact that it is close makes it worse, because your brain wants to make it fit (just as it keeps trying and failing with the optical illusion I posted that has the same issue).  The end result is that it causes cognitive dissonance, or a subconscious uneasy feeling caused by two incompatible mental models.

It isn’t just a naming or education issue.  That is why, when we were bikeshedding names, we couldn’t find any set of names that felt right.  Solving only issue 2 by renaming them to be different would still help a little, but it isn’t ideal because it only solves one of the underlying issues.

The reason picking one model and declaring it the winner is ideal, is that it gets rid of the actual cause of our problem.  

Even with this proposal, we would still have some negative transfer from other languages (expecting ‘private’ to behave based on how it has been experienced in other languages). Luckily, negative transfer is something that can be solved with training/education… even if it means learning is more difficult. We could potentially get rid of all 3 issues by getting rid of the word ‘private’ entirely as well, and calling fileprivate ‘local’ or something like that.  Local would have the connotation that things nearby could see it.

Thanks,
Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/49a95a6d/attachment.html>