[swift-evolution] access control proposal
ilya.belenkiy at gmail.com
Mon Dec 14 11:37:29 CST 2015
If only the name is a problem, I am sure that we can come up with a good
name. scoped and local are just 2 potentially good names (and the
documentation could be updated if it's decided to use scoped).
On Mon, Dec 14, 2015 at 12:31 PM Marc Knaup <marc at knaup.koeln> wrote:
> 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