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

[Jonathan Hull]

> On Mar 24, 2017, at 6:45 PM, Drew Crawford <drew at sealedabstract.com> wrote:
> On March 24, 2017 at 7:53:09 PM, Jonathan Hull (jhull at gbis.com <mailto:jhull at gbis.com>) wrote:
> 
>> It isn’t the fact that there are multiple models, but they way those models interact with each other in the brain.  You can actually have lots of different models without causing confusion, as long as the models fit well together.  It also isn’t the number of access levels that is a problem.  For example, you can have a ton of shirt sizes (XS, S, M, L, XL, XXL, 3XL) and it doesn’t cause more confusion as you add more sizes because they don’t conflict with one another.
>> 
>> A big part of the issue with our current access scheme is how similar the concepts are without being the same.  That is then made worse by the fact that they have been given similar names.
> 
> It is unclear what distinction you intend to draw here.  For example, value types and reference types are similar without being the same.  The names of both concepts also contain the substring "type".  So the difference you draw between that situation and the private/fileprivate situation is not immediately clear.
> 
The distinction between value and reference types is one of the most confusing aspects of learning to program. We are helped a bit by the fact that we use the concrete Class, Struct, and Enum.  Many programmers just think of Classes as behaving differently than Structs/Enums and don’t really think about it as value vs reference.  We never write valueType or referenceType in swift (only when having abstract discussions here on Evolution).  Notice also that swift doesn’t use the term “pass-by-reference”.  It has explicitly avoided using those terms in actual swift code.

I agree with you about statically vs dynamically dispatched being an issue.  For the most part, Swift tries to make it so we don’t ever have to think about it, but when the distinction does poke through, it can be confusing.  I think we will need to do some redesign work here when more dynamic features are added.  I had a proposal a while back to allow power users to force static dispatch by disambiguating the implementation which gets used. I will probably re-propose that when it seems in scope.

It may help if I clarify that a mental model is not how something actually works, but rather our model of how we *think* it works.  Mental models are almost always incorrect, but they are good enough to get by... for the most part. (https://www.nngroup.com/articles/mental-models/ <https://www.nngroup.com/articles/mental-models/>)

In your examples above, Swift is projecting a system image which is much simpler than the underlying concepts (e.g. your statement about static vs dynamic typing that: "I would guess the vast majority of Swift developers are not aware there's a difference at all”).  This helps to avoid confusion (except where rough spots poke through the facade).

For access controls, the user is being presented with the full complexity of that choice directly.
> Here we have two superficially similar tools with slightly different features and performance characteristics, and for most problems it does not even matter which one you choose.  
> 
This is exactly the problem. Both for access controls and dispatch.

> IMO shipping a full toolbox with plenty of overlap is one of the core values of Swift.
> 
Is it?  Can you point to an instance where a member of the core team said they are aiming for “plenty of overlap”?


>> Do you feel that allowing both scoped private & file-based private is actually important enough to warrant the significant design work it would take to bring it up to par with these other features? 
> 
> It is not clear to me what design work is actually outstanding.  I would love to see submodules, but that seems only indirectly related to visibility keywords, and I'm not aware of what you seem to believe we need.
> 
> I do use scoped access extensively, and I've left some examples of that upthread.
> 
Honestly, most of your examples could just be split into multiple files. They might also benefit from submodules.


>> It is not impossible, but it really doesn’t feel worth the effort to me (say compared to using that time/energy/thought to check off features from the generics manifesto).
> 
> Rather, as Carl Brown argued, it would take a lot of time/energy to migrate even the official projects off of private/fileprivate.  Keeping what we have is free, change is what is expensive, and this proposal is change.
> 
You are conflating effort by the swift design and implementation community with your personal effort around migration.
 

>>  In general, Swift is an opinionated language
> 
> Not clear what you mean here either.  Swift is clearly less opinionated than ObjC for example.  I am having trouble connecting this claim to a practical application.
> 
Oh, that is a quote from Lattner, when he was describing the core philosophy behind Swift.  Others can probably dig up the actual quote. It has been repeated over and over.






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