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

[Xiaodi Wu]

Chris's actual quote was:

"We intentionally want Swift to have a common 'center of gravity' and be an
'opinionated' language, rather than fall to the 'design by committee'
approach that leads to a watered-down design."

This is diametrically opposite to "shipping a full toolbox with plenty of
overlap."


On Fri, Mar 24, 2017 at 22:21 Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> 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) 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/)
>
> 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.
>
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170325/909a0e12/attachment.html>