[swift-evolution] access control proposal

[Ilya]

Classified is a nice name for this.

I think that it would not be accessible from extensions (otherwise it would
be easy to break into the internals that the class wants to make
inaccessible)

--
Ilya Belenkiy

On Mon, Dec 7, 2015 at 9:25 AM plx <plxgithub at gmail.com> wrote:

> If such an extra-private access-control level (`classified`?) existed, how
> would it be intended to behave in snippets like below?
>
>     private class Example {
>       classified var data: TopSecretData
>     }
>
>     extension Example: Equatable {
>     }
>
>     func ==(lhs: Example, rhs: Example) -> Bool {
>       return lhs.data == rhs.data
>       // ^ ??? possible or not?
>     }
>
> …(assuming the rest of the language largely behaves as-before).
>
> When such `classified` properties behave like values you could perhaps
> declare them as `private classified(set) var` but that wouldn’t really add
> much safety when they behave like references.
>
> On Dec 7, 2015, at 7:45 AM, Ilya via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Also, one problem with the current approach is that it's all or nothing.
> The classes in one file see everything from the other classes, and it may
> be useful to limit that and share only some additional APIs with those
> related classes, but not all of the implementation details / internal
> state, while still hiding those same APIs from unrelated classes.
> Currently, there is no way of doing it, even when splitting code into
> separate files (the class state must be all in one place and can't be in an
> extension).
>
> --
> Ilya Belenkiy
> On Mon, Dec 7, 2015 at 8:17 AM Ilya <ilya at harmonicsense.com> wrote:
>
>> My main proposal was not to change the semantics of private (although I
>> would like that) but to introduce a way to keep class implementation
>> details inaccessible to anything outside the class. I think that it should
>> still be possible and useful to have the current level of sharing (I would
>> just name it differently, given what private usually means in other
>> languages).
>>
>> Just as it is convenient to group several related classes that can refer
>> to each other's implementation details, it is very convenient to have
>> several classes that don't do this but are still related in other important
>> way, for example related APIs or classes that are based on the same
>> implementation idea (like array based data structures).
>>
>> Having all code in one place rather than jumping through many small files
>> is a very nice thing to have because it really helps to keep everything
>> consistent. The more manual work people have to do for consistency, the
>> more likelihood that it won't be done.
>>
>> --
>> Ilya Belenkiy
>> On Mon, Dec 7, 2015 at 12:21 AM John McCall <rjmccall at apple.com> wrote:
>>
>>>
>>> > On Dec 5, 2015, at 8:39 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.
>>>
>>> But on the flip side, with your proposed semantics for private, it would
>>> be impossible to write a group of related types, functions, and extensions
>>> that do need to refer to each other’s internal details without exposing
>>> those details to the entire module.  That’s not really acceptable.
>>>
>>> The Swift language rule encourages you to put independent definitions in
>>> different files.  That definitely means that, if you want to enforce very
>>> tight separation of concerns, you’ll end up with more and smaller files.
>>> You haven’t explained why that’s really a *problem*, though.
>>>
>>> John.
>>
>>  _______________________________________________
>
>
> 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/20151207/9206d855/attachment-0001.html>