Turning access control into SEP ;-)


(Tino) #1

I don't remember the exact location, but there have been several contributions from active members of the community who stated they would be fine with just two levels of access control — but I haven't seen this standpoint discussed at all.
Most likely, that is because it contradicts the perceived spirit on swift-evolution, but who knows, maybe this opinion isn't as isolated as we think?
To be honest, I don't expect that such a drastic simplification would be seriously considered, but I think it's a good exercise to take such an extreme perspective.

[If anyone would like to participate in this experiment, you may prefer to skip the rest for now to avoid bias :wink: ]

[personal results start here]

I don't need access control as a tool to enforce my opinion onto others, so I'm not generally opposed to a compiler-orientated model, where access limitation would only be used to allow better optimisation.

What I don't want to loose is a way to document intensions which helps users of an API — but this could be something different than a compilation error that tells me I'm trying to call a method that I'm not allowed to use.
In my day to day routine, the language level actually isn't that important:
When I work in an environment that is new to me, a method that is missing in autocompletion is as protected as a private member, and it's similar for overrides.
So I would be fine with a set of annotations that are ignored by the compiler, but used by the IDE. Actually, such an approach could have saved me from stupid errors in the past, because the compiler only knows if I'm allowed or forbidden to do something (anyone else ever had fun with UITableView.didDeselectRowAtIndexPath? Alphabetical order is a really inconvenient sometimes, and there is no way for the compiler to detect such problems reliably).


(Andrey Fidrya) #2

I use this access control model. As I usually split large classes into multiple files using extensions, marking members "fileprivate" or "private" initially is pointless.

Of course, "private" can be used for small classes which don't need to be split, but that would be inconsistent. Also the code looks tidy without being cluttered with "private" in every declaration.

It's too bad that compiler can't protect classes inside the same module from accessing implementation details of other classes using this approach, but I sacrificed this for freely splitting code between files. Imo, ideal access model for this coding style would be "type+extensions" visibility default with explicit "module" ("internal") and "public" modifiers.

Andrey

···

On 17 Apr 2017, at 14:17, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

I don't remember the exact location, but there have been several contributions from active members of the community who stated they would be fine with just two levels of access control — but I haven't seen this standpoint discussed at all.
Most likely, that is because it contradicts the perceived spirit on swift-evolution, but who knows, maybe this opinion isn't as isolated as we think?
To be honest, I don't expect that such a drastic simplification would be seriously considered, but I think it's a good exercise to take such an extreme perspective.

[If anyone would like to participate in this experiment, you may prefer to skip the rest for now to avoid bias :wink: ]

[personal results start here]

I don't need access control as a tool to enforce my opinion onto others, so I'm not generally opposed to a compiler-orientated model, where access limitation would only be used to allow better optimisation.

What I don't want to loose is a way to document intensions which helps users of an API — but this could be something different than a compilation error that tells me I'm trying to call a method that I'm not allowed to use.
In my day to day routine, the language level actually isn't that important:
When I work in an environment that is new to me, a method that is missing in autocompletion is as protected as a private member, and it's similar for overrides.
So I would be fine with a set of annotations that are ignored by the compiler, but used by the IDE. Actually, such an approach could have saved me from stupid errors in the past, because the compiler only knows if I'm allowed or forbidden to do something (anyone else ever had fun with UITableView.didDeselectRowAtIndexPath? Alphabetical order is a really inconvenient sometimes, and there is no way for the compiler to detect such problems reliably).

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution