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.
Note also that your list above is a list of typical stumbling blocks for new
programmers in most languages. Swift has actually done a remarkable job with
most of these through careful design of the way that they are framed / exposed
to the programmer. In general, these things are well separated from each
other.
I do not think Swift has done even a *good* job framing these concepts. For
example
protocol Foo {
func foo() { }
}
extension Foo {
func bar() {}
}
One of these is statically dispatched and the other one is dynamically
dispatched. I would guess the vast majority of Swift developers are not aware
there's a difference at all, let alone can explain why one is slower in a
benchmark.
Swift is good at giving programmers flexibility in their tools. 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. IMO shipping a full toolbox with plenty of overlap is
one of the core values of Swift.
I would suggest that the practicable reason we are talking about removing
private/fileprivate instead of protocol/extension or reference/value is that
while `extension` etc. makes your code more powerful, `private` makes it less
powerful. It is not obvious to everyone why less power is desirable and so
here we are.
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.
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.
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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
