[swift-evolution] access control

Mon Jan 25 16:16:26 CST 2016

I want to try and offer a concrete example of the usefulness of this idea in real code.  I had a look through the popular Alamofire library.  Every use of `private` in that library could actually use `local` instead if it existed.  

In some cases these would be equivalent because there is only one type / scope in the file anyway.  However, in most cases they actually do communicate something different.  There are a few ways this is possible:

In some cases, this is because there is a nested type involved and the `private` members are inside the nested type.  They should not be visible outside the scope of the nested type.  

In other cases, there are extensions of other types.  These extensions add methods that are closely related to the primary type / extension involved in the file.  The private members of the type 

One other case that didn’t appear in Alamofire, but I have seen elsewhere is a case where you conform several types to the same protocol (usually a simple protocol) in the same file.  In this case there may be helper methods that support the protocol implementation but should not be visible to the other implementations of the protocol that are in the same file.

It seems like “current scope” is probably the most frequent intent of `private`, while `file` is actually less commonly necessary, but is certainly the right thing in some cases (and is much better than `friend`).

I agree with Ilya that it would probably be better if `private` was actually scope-based.  Rather than `internal` we could have `module` and `file` access modifiers to make it clear when there is broader visibility and make it clear exactly what that visibility is.  This would be my preference and I think it would provide the most clarity.

On the other hand, changing the meaning of `private` is probably not going to happen at this point (or would at least likely receive even more pushback than `local`), thus the proposal to add a new modifier and not change the meaning of existing modifiers.

I suggest those who are pushing back on this look through some real-world code.  How often do you actually need the file-level visibility of a `private` member?  This is likely only needed in a significant minority of uses of `private`. 

Saying what you mean and meaning what you say adds clarity to the code.  It helps readers and future maintainers of the code understand the thinking of the author.  Right now, we do not have the ability to say what we actually mean with regards to access control in a significant number of cases.   It is the inability to express the most frequent intent of `private` that Ilya’s proposal is attempting to address (while not taking away the necessary ability to share visibility within a file in some cases).  

-Matthew

> On Jan 25, 2016, at 3:44 PM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Am 25.01.2016 um 20:33 schrieb Ilya Belenkiy via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>>> There would be no difference at all between local and private if you had one class per file.
>> 
>> AND if this rule was enforced by the compiler. This would also have to be one extension per file, even if it’s one line of code.
> 
> Why should the compiler enforce this? That’s my design decision.
> For the same reason the compiler does not enforce where I have to put „private“ (it can make suggestions like many IDEs do and offer fix-its, like „this method can be made private as it is not used outside the class“ or „this class can be put into its own file as its private methods are not used by other components in this file“.
> 
> 
>> Since this rule is not enforced, at most, this is coding by convention. By the same reasoning, we could have just one type, object, and name every variable by including the type name we want it to be. No need for a strong type system. And anyone insisting that we need a type system would surely be wrong because there would be a very simple solution — just make the type name part of the variable name.
> 
> No, there is a clear difference: making the type name part of the variable name enforces no compiler checks whereas putting something into different files does. 
> 
> 
>> And yet, Swift does have a strong type system. It should have strong access control for the very same reason: the compiler can enforce it and eliminate lots of human errors.
>> 
>>> It seems very very bold to me to say that Swift "doesn't support encapsulation" but that local would solve that problem.
>> 
>> And yet both statements are true: it is possible to break the class invariant right now without modifying the class source code, and “local” would solve that problem.
> 
> But you need to modify the file. With „local“ it is possible to break the class invariant without modifying the source code of a private method just by adding some public methods that call the private ones. Seems quite the same to me.
> 
> That being said I have nothing against a „local“ access modifier but I personally don’t see a real need for it. I would wish for a better name, though...
> 
> -Thorsten
> 
> 
>> 
>>> On Jan 25, 2016, at 1:43 PM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>>> 
>>> There would be no difference at all between local and private if you had one class per file. It seems very very bold to me to say that Swift "doesn't support encapsulation" but that local would solve that problem.
>>> 
>>> Félix
>>> 
>>>> Le 25 janv. 2016 à 13:16:45, Ilya Belenkiy via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>>> 
>>>>> A language does not need to have strict access controls in order to be considered OO. 
>>>> 
>>>> This is a matter of terminology. It still doesn’t change the fact that data encapsulation is a fundamental feature of object oriented programming that is currently not supported.
>>>> 
>>>>> You don’t even need “classes” to do OO either.
>>>> 
>>>> In this terminology C is also object oriented. You can have opaque pointers to structs with functions around them. Swift current support for data encapsulation is exactly like that. But people don’t do this kind of programming in C precisely because the compiler can provide a lot more help than this.
>>>> 
>>>>> This really seems like an academic problem vs a pragmatic problem. 
>>>> 
>>>> 
>>>> It’s very pragmatic. With properly marked access level and well designed interfaces, the class implementor may rely on the compiler to ensure that the class invariants / internal state will not become corrupt. Without it, the code is much more likely to break due to human error. It’s the same reasoning as with having ARC rather than doing manual retain / release and having destructors that are called automatically instead of calling cleanup code manually.
>>>> 
>>>>> There’s also no concept of “friend” in Swift either
>>>> 
>>>> file based access level is a good solution for this. But it’s not a solution at all for real data encapsulation.
>>>> 
>>>>> On Jan 25, 2016, at 12:09 PM, David Owens II <david at owensd.io <mailto:david at owensd.io>> wrote:
>>>>> 
>>>>> 
>>>>>> On Jan 25, 2016, at 4:47 AM, Ilya Belenkiy via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>>> Data encapsulation is indeed one of the cornerstone of OO, but every design decision is a trade-off. Is Python not object-oriented because they lack a private keyword, and have the convention of marking internal items with a leading underscore?
>>>>>> 
>>>>>> 
>>>>>> Then Python has the same problem. A language that *supports* OOP should not leave such an important part of OOP to coding by convention. 
>>>>> 
>>>>> I think this where you are being lead astray. A language does not need to have strict access controls in order to be considered OO. Languages like C#, Java, and to some extent, C++ tend to make people think this. You don’t even need “classes” to do OO either.
>>>>> 
>>>>>>> The best anyone can do is make the breaking of encapsulation an explicit choice. I’m intuiting that you think that writing code into the file where the class was defined is not explicit enough.
>>>>>> 
>>>>>> Right now, it’s impossible to make the distinction: is something truly private or can be used safely in the same file? The language has no way of expressing it. The class internal state is not encapsulated outside the bounds of the class.
>>>>> 
>>>>> This really seems like an academic problem vs a pragmatic problem. There’s also no concept of “friend” in Swift either, which is another construct that would have be invented to allow the “private” things to be used by others elsewhere. 
>>>>> 
>>>>> -David
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160125/788e5cc2/attachment.html>