[Draft] Fix Private Access Levels


(Joanna Carter) #1

From my point of view the "underlying issues with access" is that we have no well-designed scoped access modifiers in addition to module/file access levels. I do think they are two axis of the access control/documentation, and should work together to aim the better code quality and 'simplicity' in all meanings.

I have started a new thread "Analysis of existing scopes" in the hope of trying to outline more precisely what we currently have in terms of scopes and where I see inconsistencies/problems.

I hope it is of more use than noise :slight_smile:

From first analysis, I have found that we may actually need both private *and* fileprivate ???!!!

The one way I can think of scoped access modifiers is that they should have explicit and clear naming, even if this will lead to more massive syntax (like Matthew Johnson suggested scoped(scopeName)). While keep public/internal/private(as was in Swift2) names simple and easy to use.

I, personally, would be wary of settling on names at this stage, preferring to define exactly what we've got currently, any shortcomings, and what we would be happy with in terms of scopes. Of course, we will have to use some sort of naming convention, just to be able to discuss things but, whether those names end up being final should not be of primary concern.

···

--
Joanna Carter
Carter Consulting


(Jon Hull) #2

From my point of view the "underlying issues with access" is that we have no well-designed scoped access modifiers in addition to module/file access levels. I do think they are two axis of the access control/documentation, and should work together to aim the better code quality and 'simplicity' in all meanings.

I have started a new thread "Analysis of existing scopes" in the hope of trying to outline more precisely what we currently have in terms of scopes and where I see inconsistencies/problems.

Thanks for doing that. I think it is useful to step back and look from a different angle from time to time.

I hope it is of more use than noise :slight_smile:

From first analysis, I have found that we may actually need both private *and* fileprivate ???!!!

I think the question is: Do we actually need (scoped) private? If we do, then we still need fileprivate. If not, then we could get away with just ‘fileprivate’ which we would spell ‘private’.

A third option is just to have ‘private' mean private to the current submodule (which would be the file unless otherwise specified). Then, assuming we don’t need (scoped) private, we wouldn’t need fileprivate either…

Thanks,
Jon

···

On Feb 22, 2017, at 8:26 AM, Joanna Carter <joanna@carterconsulting.org.uk> wrote: