[swift-evolution] Class scoped access level

[Tom Bates]

Reading between the line of what T.J has said I can see he is keen to see
this become reality!

It is very easy to come across examples where the current access level do
NOT work well and are inhibiting clean, readable code. Which, in my
opinion, when considering any kind of scale is probably the most important
thing to be able to maintain, extend and ultimately reduce bugs.

I agree that the obvious concern would be complexity.
One solution that would eliminate any extra complexity would be to allow
extensions to access all private variables and functions from it's initial
declaration.
This would only be the case when the extension's declaration is within the
defining module (prevents people accessing private variables when using
submodules)
To restrict access to extensions of the class you would use the
`fileprivate` access control.
If you want access to a var or func outside the defining module then it has
to be public as is the case now.

Again, this would require no migrations to existing code that I can see.


On Sat, 10 Sep 2016 at 13:17 T.J. Usiyan <griotspeak at gmail.com> wrote:

> I am firmly against this. The 5 levels that we have cover us well and have
> enough complexity already.
>
> On Sat, Sep 10, 2016 at 5:23 AM, Tom Bates via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I agree that classprivate would probably not work, maybe
>> constructprivate? but then you are leaving our enum etc.
>> With the `internal(class)` suggestion, if declaring a var such as `
>> internal(set) var name: String?` would this become `internal(class, set)
>> var name: String?`
>> Also there would need to be some kind of compile check either way because
>> if you declared an enum for example outside of a constructor you would not
>> be able to mark it as our new constructor only access level or it would
>> become inaccessible throughout the project.
>>
>> Re: submodules, they are indeed overkill for this. As you would need a
>> separate submodule for each class you wanted to do this with and then run
>> the risk of inter coupling lots of different really small submodules.
>>
>> Suggestions so far:
>> `classprivate`
>> `constructprivate`
>> `private(instance)`, `private(instance, set)` - problem -> how would this
>> work? `public private(instance, set)`
>> `internal(class)`
>>
>> Personally I think a name like `classprivate` or `constructprivate`,
>> although not particularly well named would reduce complexities with private
>> setters syntax and keep migrations much simpler.
>>
>>
>> On Sat, 10 Sep 2016 at 07:09 Adrian Zubarev via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> I don't think submodules would solve it nicely. Each module/submodule
>>> will require it's own namespace + it feels like an overkill to create
>>> submodules for a few types. `internal(xyz)` seems to me like a better
>>> solution. And yes this is purely additional and nothing for phase 1.
>>>
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>>
>>> Am 9. September 2016 um 19:09:12, Xiaodi Wu (xiaodi.wu at gmail.com)
>>> schrieb:
>>>
>>>> Isn't the general solution to this problem submodules? In any case,
>>>> seems like it'd be out of scope for Swift 4 phase 1.
>>>>
>>>>
>>>> On Fri, Sep 9, 2016 at 11:34 AM, Adrian Zubarev via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> There must be a better solution to this problem, because you might
>>>>> also extend value types from different files. That would mean, we'd need
>>>>> `structprivate` `protocolprivate` etc.
>>>>>
>>>>> How about: `internal(class)` etc. ? Or something like
>>>>> `internal(private)` to rule them all (I don't like the last name, but
>>>>> something that would rule them all would be nice to have)!
>>>>>
>>>>>
>>>>> --
>>>>> Adrian Zubarev
>>>>> Sent with Airmail
>>>>>
>>>>> Am 9. September 2016 um 17:49:29, Tom Bates via swift-evolution (
>>>>> swift-evolution at swift.org) schrieb:
>>>>>
>>>>>> There is currently no way of accessing "shared code" from extensions
>>>>>> declared outside the base .swift file
>>>>>>
>>>>>> I would love to see along side the new fileprivate access level a
>>>>>> classprivate access level that would allow any extension declared outside
>>>>>> of the original .swift file to access these properties and functions in an
>>>>>> attempt to reuse code.
>>>>>>
>>>>>> an example is below...
>>>>>>
>>>>>> =================
>>>>>> //MyClass.swift
>>>>>> public class MyClass {
>>>>>>
>>>>>> classprivate func sharedFunction() {
>>>>>>   self.function1()
>>>>>>   self.function2()
>>>>>> }
>>>>>>
>>>>>> fileprivate func function1() {}
>>>>>> fileprivate func function2() {}
>>>>>> }
>>>>>> =================
>>>>>>
>>>>>> =================
>>>>>> //MyClass+Save.swift
>>>>>> extension MyClass {
>>>>>>
>>>>>> public func save() {
>>>>>>   self.someFunction()
>>>>>>   self.sharedFunction()
>>>>>> }
>>>>>>
>>>>>> fileprivate func someFunction() {}
>>>>>> }
>>>>>> =================
>>>>>>
>>>>>> Currently to achieve anything like this you would have to make the
>>>>>> "core" functions public or internal or write the whole thing in a single
>>>>>> file which as I understand it is not optimal for the compile speed and can
>>>>>> get unmanageable for large classes. This would allow a more managed file
>>>>>> structure and the separation of related functions from the core declaration.
>>>>>>
>>>>>> There would be no migration needed I don't think as the impact on
>>>>>> current code would be zero until the developer adopts the new access level
>>>>>>
>>>>>> Regards,
>>>>>> Tom
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>> _______________________________________________
>>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160910/3afac8b3/attachment.html>