[swift-evolution] access control proposal
Marc Knaup
marc at knaup.koeln
Mon Dec 14 11:31:27 CST 2015
Even the Swift documentation refers uses the terms "scope" and "scoped" to
refer to the access *scope* a symbol has.
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID3
It's unlikely that an access modifier will ever be called like that since
it's just bogus and confusing.
On Mon, Dec 14, 2015 at 6:25 PM, Matthew Johnson <matthew at anandabits.com>
wrote:
> The idea of calling this 'local' was abandoned a long time ago. Any
> proposal around this will be using 'scope' or 'scoped'.
>
> Sent from my iPad
>
> On Dec 14, 2015, at 11:22 AM, Marc Knaup <marc at knaup.koeln> wrote:
>
> What about "more private" or "really private"? :)
> j/k
>
> I also thought about "local" but it's also not obvious what exactly that
> means.
> Maybe "my"? my var xyz = …
>
> On Mon, Dec 14, 2015 at 6:17 PM, David Owens II via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On Dec 14, 2015, at 8:58 AM, Matthew Johnson <matthew at anandabits.com>
>> wrote:
>>
>> I agree that you can concoct arbitrarily complex scenarios and a line
>> must be drawn somewhere. IMO the best place to draw the line is when you
>> start considering something that is not super straightforward to explain
>> and is not a natural extension of the obviously necessary access modifiers.
>>
>>
>> IMO ‘scope’ passes this test and all of the complex counter-examples do
>> not. It is the logical conclusion of a simple narrowing of visibility from
>> “everyone” to “module” to “file” to “scope”. It is simple to explain and
>> understand. Those who don’t like it don’t need to use it. Anything more
>> complex is unlikely to pass such a test.
>>
>>
>> I think the simplest counter-example is your own example for extensions.
>> Each extensions will need access to different internals of the the type
>> it’s applied to. So when it comes time to add that extension, you’ll be
>> forced to promote the access control from “local” to “private”.
>>
>> Another straight-forward one is a subclass. Since “local” would be
>> “scope” based, a subclass would also knot have access to those members
>> defined as local in the super class, so they’d have to be promoted to
>> private and thus available to all code within the file.
>>
>> I think “local” fits this definition:
>>
>> IMO the best place to draw the line is when you start considering
>> something that is not super straightforward to explain and is not a natural
>> extension of the obviously necessary access modifiers.
>>
>>
>> It’s not an obviously necessary modifier as it’s usage is extremely
>> limited and requires to be bounced up a level is a lot of design
>> considerations, such as extensions and subclasses. There are certainly
>> times where “local” could be used, but my opinion is that it’s not worth
>> complexity for the limited value that it actually brings to the table.
>>
>> -David
>>
>> _______________________________________________
>> 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/ef7db2c6/attachment.html>
More information about the swift-evolution
mailing list