[swift-evolution] access control

Dave Abrahams dabrahams at apple.com
Sat Jan 23 16:45:37 CST 2016


on Sat Jan 23 2016, Ilya Belenkiy <ilya.belenkiy-AT-gmail.com> wrote:

> Yes, but that understanding doesn't need to be as deep. 

Can you explain that statement?  I don't see how it can possibly be
true.

> Also, with The API based approach, the compiler can enforce the class
> author's intent, and the intent is very clearly spelled out.

I don't see how that's a difference in Swift.  If you, as a class
author, don't have control over the contents of the file your class is
defined it, other people can break your class.  If you do, you can
prevent them from breaking it.

> On Sat, Jan 23, 2016 at 5:20 PM Joe Groff <jgroff at apple.com> wrote:
>
>> On Jan 23, 2016, at 2:14 PM, Ilya Belenkiy via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Anyone who can "add more code to the same file" can just as easily
>> modify/extend the class.
>>
>>
>> Yes, but with an API based access control, anyone modifying / extending
>> the class can instantly see the author’s intent from the API declaration,
>> and the compiler can prevent *accidental* misuse. Deliberate misuse cannot
>> be stopped no matter what access control is in place (as long as the coder
>> can modify the code in the module). But at least with an API based access
>> control, a deliberate misuse is very easy to spot when debugging /
>> reviewing the code. With a file based access control, the only way to tell
>> if an API is really private or can be safely used anywhere in the same file
>> is to read the comments / source code. And it’s much easier to miss in
>> maintenance, debugging, or code reviews. The only way to make it obvious in
>> the current model is to adopt a convention like _ in front of methods.
>>
>> There's nothing about extending a class that ought to raise a red flag in
>> Swift, because it's perfectly legit to do so and use only the class'
>> public APIs.
>>
>>
>> Unless the programmer extends a class in the same file. Then he can call
>> anything marked private, and it’s impossible to tell without reading the
>> code whether it violates the class invariants. There is no way to express
>> this in Swift today. My proposal for local / scoped access control would
>> solve this.
>>
>>
>> This doesn't change if you constrain access to a class's members to the
>> primary class declaration. Anyone extending the class within the 'class Foo
>> { }' braces also has to understand the class invariants.
>>
>> -Joe
>>
>>
>>  we didn't do file-level access control because it was easier; we did it
>> because we thought it was a better model for Swift, where types are
>> liberally open for extension.
>>
>>
>> That’s what I assumed until I saw someone say it in this list when someone
>> else raised a similar concern. Types in C++ and C# are also liberally open
>> for extension, but they provide much better support for expressing the
>> intent of an API and protect against accidental misuse.
>>
>> On Jan 23, 2016, at 3:45 PM, Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> on Sat Jan 23 2016, Ilya Belenkiy <swift-evolution at swift.org> wrote:
>>
>> I hope that access control can be revisited. It is the number one
>> complaint about Swift that I hear from experienced developers. The
>> current solution came as a complete surprise to every ObjC developer
>> I've talked to. The natural expectation was that a strong access
>> control system would be part of a strong type system. I already
>> submitted a pull request with a proposal for this after a lengthy
>> discussion here, but so far it was ignored. I hope that this can be
>> revisited. Even if most people who responded earlier in this list
>> decided that they were happy with the current state, it represents a
>> tiny fraction of people using the language, and at least all the
>> people I talked to strongly disagree but just aren’t on the list.
>>
>> Right now access control is file based and not API based. This is much
>> easier to implement but useless to express that certain elements of a
>> class are implementation details that are not meant to be used
>> anywhere else (someone can add more code to the same file and get
>> access to the implementation details without modifying the
>> class).
>>
>>
>> I agree that our current access control has real weaknesses, but I don't
>> agree you've identified one above.  Anyone who can "add more code to the
>> same file" can just as easily modify/extend the class.  There's nothing
>> about extending a class that ought to raise a red flag in Swift, because
>> it's perfectly legit to do so and use only the class' public APIs.
>>
>> I'm going to let others respond to the rest of this in more detail, but
>> I should also add that we didn't do file-level access control because it
>> was easier; we did it because we thought it was a better model for
>> Swift, where types are liberally open for extension.
>>
>> It’s also impossible to hide APIs that are meant only for
>> customization points of subclasses.
>>
>>
>> Some of these problems could be solved with a convention like putting
>> _ in front of protected and __ in front of private methods, and Cocoa
>> uses a similar approach today. But this “solution” is in the same
>> category as using prefixes to determine types. If Swift aims to have a
>> strong type system, and it’s described as one of advantages of Swift
>> over ObjC, it should help enforce this at the language level.
>>
>> .NET has a good solution that respects the OOP terminology and deals
>> with accessibility in modules and at the API level:
>> https://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx
>>
>> I think that a similar approach would work much better in Swift.
>>
>>>> Ilya Belenkiy
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> Cheers,
>>
>> --
>> -Dave
>>
>> _______________________________________________
>> 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
>>
>>

-- 
-Dave


More information about the swift-evolution mailing list