[swift-evolution] access control proposal
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.
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>
> 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"? :)
> I also thought about "local" but it's also not obvious what exactly that
> 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>
>> 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.
>> swift-evolution mailing list
>> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution