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@swift.org> wrote: > On Mar 24, 2017, at 6:45 PM, Drew Crawford <d...@sealedabstract.com> > wrote: > > On March 24, 2017 at 7:53:09 PM, Jonathan Hull (jh...@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@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