[swift-evolution] access control proposal

Ilya Belenkiy ilya.belenkiy at gmail.com
Tue Dec 15 06:10:00 CST 2015

This is a matter of opinion. I think that the proposal is very much in line
with Swift's emphasis on strong types and protocols and adds clarity about
where an API can be used.

Ilya Belenkiy

On Mon, Dec 14, 2015 at 4:11 PM Colin Cornaby <colin.cornaby at mac.com> wrote:

> I don't think this analogy follows. Books have division lines of pages or
> chapters that compartmentalize information. In the same way, development
> projects traditionally have a separation of concerns that are organized
> using different source code files. I don't know if a "gazillion" accurately
> captures the number of files required to separate concerns. On the other
> hand, I'm also not sure if Swift should try to enforce good development
> practices as policy (but I like the practice it's trying to support here.)
> I'm just watching this from the sidelines, but I haven't seen a compelling
> example case anywhere in the discussion that would lead to just an
> unmaintanable number of files. Even for multiple teams all working on the
> same source... separation of files seems like the cleanest solution.
> As others have mentioned, iOS and Mac development (as well as open source
> Swift) seems to be going in the direction of a single application or
> project containing multiple modules. Mac has been doing that with great
> success for a long time. Given that's the direction things are going,
> private as it exists now even seems a little heavy for a lot of uses. It's
> completely realistic the projects are going to start separating concerns
> over module boundaries and not just source file boundaries. This proposal
> just seems to be going the opposite way that Swift and Apple platform
> development is going.
> Files are easy to understand, and they're lightweight, and I just haven't
> been convinced that files with small amount of source are even a bad thing,
> nor have I seen Swift projects out in the wild that have too many short
> Swift source files that is a result of language restrictions. Do you have
> any examples of projects out in the community?
> On Dec 14, 2015, at 11:42 AM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
> wrote:
> Please take a look at the other posts today. I addressed this concern
> earlier. In one sentence, just like you wouldn't want to put every
> paragraph of a book or every section of an article in an encyclopedia in a
> separate file, you wouldn't want to end up with a gazillion files just to
> ensure that implementation details of an API stay hidden in a way that is
> enforced by the compiler.
> --
> Ilya Belenkiy
> On Mon, Dec 14, 2015 at 2:19 PM Colin Cornaby via swift-evolution <
> swift-evolution at swift.org> wrote:
> (I'm reading the upstream discussion but I'll reply here.)
>> I don't know if I really like the pattern this is trying to support. I
>> like that Swift makes it cleaner to include multiple types in a single
>> Swift file. But I feel like this proposal is trying to take things too far
>> the other way. Types that should should only see each other from a non
>> "friends" role should be in separate files.
>> What's proposed doesn't really harm someone who likes the "multiple file"
>> style directly, but I don't want to see projects where everything gets
>> jammed into one file. I think keeping the scope of private (with no new
>> keywords) to the same file encourages good coding practices.
>> I've really liked the balance Swift strikes in this case. I feel like
>> this discussion is going to come down to opinion, but projects that I've
>> worked in that have tried to over compact have always run into issues. I
>> don't know if it's the role of the language to push an ideology either way,
>> but personally I like the direction Swift is pushing. Files make for good
>> scope boundaries.
>> On Dec 05, 2015, at 08:40 PM, Ilya via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> I think the it would help a great deal to have an access level modifier
>> that is really private and visible only inside the class itself. Right now,
>> the only way to hide implementation details for a class is to hide the
>> class code in a separate file, which is very inconvenient for several
>> reasons:
>> 1) the meaning of the code changes depending on which file the class is
>> in. It's very easy to accidentally expose class internal details and then
>> call class elements that are meant to be used only inside the class. Having
>> a keyword for class internals will allow the compiler to ensure that only
>> the public API for the class is used from the outside world. The user can
>> check types on his own, but it's better that the compiler does it
>> automatically. Similarly, the user can check that only the proper APIs are
>> called, but it's better that the compiler does it automatically.
>> 2) accessibility by file structure may cause some really short files.
>> 3) It's impossible to group related classes in one file but still hide
>> implementation details inside each class
>> I think that it the best solution is to make private keyword do what it
>> states -- keep the class element private to the class. But if it's really
>> important to have a separate keyword for backward compatibility, it would
>> be the next best thing.
>> --
>> Ilya Belenkiy
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> 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/20151215/cd8bf9d1/attachment.html>

More information about the swift-evolution mailing list