[swift-evolution] access control proposal

[Ilya Belenkiy]

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>