[swift-evolution] access control proposal

[Ilya Belenkiy]

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/20151214/60aa1a2a/attachment.html>