[swift-evolution] access control proposal

[Ilya]

Hi Matthew,

Maybe you could write the proposal? I'd be happy to do it, but it was your
idea. Also, I think that you will express it better.

--
Ilya Belenkiy
On Mon, Dec 7, 2015 at 2:11 PM Matthew Johnson <matthew at anandabits.com>
wrote:

> Glad you like my reframing!  Is anyone planning to write a proposal for
> this?
>
> Sent from my iPad
>
> On Dec 7, 2015, at 1:00 PM, Ilya <ilya at harmonicsense.com> wrote:
>
> Yes, that's a great idea!
>
> --
> Ilya Belenkiy
> On Mon, Dec 7, 2015 at 1:35 PM Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>> I think what you are really trying to accomplish is to restrict access to
>> a member to the scope in which it is declared, which just happens to be a
>> type declaration.
>>
>> By looking at it in terms of scope the feature would be come more
>> generally applicable.  For example, you could have a 'classified' member in
>> an extension which is only visible inside the body of the extension.  This
>> would be useful if the extension contains helper methods as part of its
>> implementation.
>>
>> I would absolutely support extending Swift's scope-based access control
>> to allow for more granular control of visibility within a file by extending
>> it to syntactic scopes.  It seems like a pretty natural enhancement to the
>> existing feature.
>>
>> Sent from my iPad
>>
>> On Dec 7, 2015, at 11:02 AM, Ilya <ilya at harmonicsense.com> wrote:
>>
>> If it is not allowed in extensions or subclasses (and it shouldn't), the
>> model is still very simple.
>>
>> I understand the current model, but I think that there is a lot of value
>> in getting the compiler's help in ensuring that class internals cannot be
>> broken by anything outside the class.
>>
>> The current model doesn't solve this problem well. Putting everything in
>> separate files seems like a very unfortunate workaround.
>>
>> --
>> Ilya Belenkiy
>>
>> On Mon, Dec 7, 2015 at 9:41 AM Matthew Johnson <matthew at anandabits.com>
>> wrote:
>>
>>> I was not sure how I felt about Swift's access control when it was first
>>> announced but it didn't take long for me to believe it strikes a pretty
>>> good balance between complexity and ability to hide implementation details.
>>>
>>> It follows a very straightforward scope-driven strategy.  If it is
>>> extended further I would like to see any enhancements follow the same
>>> scope-driven strategy rather than being type-driven as is seen in other
>>> languages.  Proposals along these lines might be interesting to consider
>>> and might be able to accomplish what you are hoping to accomplish while
>>> affording additional flexibility.
>>>
>>> In a language where distributing the implementation of a type across
>>> several extensions sometimes in different files a type-driven access
>>> control model doesn't make a lot of sense to me.  I think it has a lot of
>>> potential to be confusing.
>>>
>>> What would it mean to limit access to a member to the type itself in
>>> Swift?  Would an extensions in the same (or different) files be able to see
>>> the member?  What about extensions in a different module?  And what about
>>> subclasses? Subclasses probably wouldn't have visibility to them, but any
>>> discussion of something like this will probably lead to discussion of
>>> protected as well.
>>>
>>> Sent from my iPad
>>>
>>> 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/20151208/098243dd/attachment.html>