> On Oct 30, 2017, at 2:23 PM, Mike Kluev <mike.kl...@gmail.com> wrote:
>
> On 30 October 2017 at 19:49, Adam Kemp <adam_k...@apple.com
> <mailto:adam_k...@apple.com>> wrote:
>
> How do you know there’s not an extension in this file without looking? If you
> don’t know then you have to check. That puts it in the same bucket as
> internal or public. The set of files you have to search through for usages is
> the same.
>
>
> I'd just search for "extension SomeClass", Xcode search result window will
> list all files that have it.
> or I will list all the users of "foo" if that's the one I am changing.
When you do that search, which files do you include in the search? That’s the
key.
>
> the good guideline from Obj-C was (and still is) using
> "SomeClass+ExtensionName" file naming convention that also helps.
That’s not sufficient because there’s nothing in the language that would force
people to follow this convention, and you can have extensions in any file for
any class.
The point I’m trying to make, again, is that the set of files that you would
have to search through is the same. Once you know the set of files that need to
be searched you can just search for actual usages of the API you’re changing
(the method or property or whatever). The important thing is to know which
files need to be searched in the first place. That’s what access level really
controls.
Each access level implies a unique set of files that have to be searched.
Public = all files in all clients. Internal = all files in this module. File
private = just one file. Private = just one part of one file.
“specialprivate", by allowing any extension to access the API, would imply the
same set of files as either internal or public. You can’t know ahead of time
whether some random file in your module might make an extension that access
that API so you have to search all files within that module. You would perform
the search exactly the same way. It doesn’t help you as a library maintainer.
You’re not going to save work by making something “specialprivate” instead of
internal. Worst case is you actually convince yourself that you don’t have to
search the whole module, and then you break something because of that
misunderstanding. That’s why internal is better. It avoids obfuscating the
actual implications of that access level.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
