Late to the party here
* What is your evaluation of the proposal?
I’m -1 on this. The proposal is not a difficult read, but may have been simply
more simply named “Remove Scoped Access Level/Revert SE-0025” as that is what
is being proposed. “Fix” seems to me to be a unfortunately worded judgmental
proposal title.
* Is the problem being addressed significant enough to warrant a change?
No. I consider myself to be a fairly “new/n00b” Obj-C/Swift developer.
Although SE-0025 was a change that required source changes when implemented,
the reasoning was not difficult to understand and changes were simple to make
once identified. Here they are from SE-0025
public: symbol visible outside the current module
internal: symbol visible within the current module
fileprivate: symbol visible within the current file
private: symbol visible within the current declaration
Moving forward these changes are not difficult to comprehend. I tend to make
_everything_ “private” up front so I don’t have any API leakage. Then dial
back to “fileprivate” as needed. It’s not difficult for me I guess. As such,
I don’t believe that this change was “Actively Harmful”, especially for new
developers who have a clean slate or simply are leaving everything unmarked
(internal) anyhow until they move up to more advanced topics. Unraveling a
generic or functional code someone else wrote uses way more cognitive power.
I’d like to address the suggestion that the migration for SE-0159 could
“simply” be a search and replace without loss of functionality. This doesn’t
make sense if you consider the entire code lifecycle. Sure the code gets
migrated and compiles. This is fine if they code _never_ has to be read again.
But as we know, code is written once and _read many times_ as it will need to
be maintained. The distinction between private and fileprivate contains
information, and although it may work correctly now, some information meant to
help maintain that code has been lost if these keywords are merged and the
functionality of scoped access is removed. So yes if you don’t maintain the
code where this migration takes place, this would be ok. But Swift strives for
readability. Moving classes to separate files to address these issues, creates
a multitude of Bunny classes where again for readability some classes belong
together in the same file for ease of comprehension (again, code is written
once , read many times)
* Does this proposal fit well with the feel and direction of Swift?
The spirit of the proposal to simplify access levels is well taken. This
proposal however simplifies at the expense of lost functionality (Scoped Access
levels) with no replacement. The threads talk a about submodules and other
solutions that could fill this gap that are not on the roadmap, planned or
possible which makes them non-admissible in considering this proposal.
* If you have used other languages, libraries, or package managers with a
similar feature, how do you feel that this proposal compares to those?
I am more familiar with scoped access so perhaps that feels more natural to me.
But with the current implementation Swift users can choose whether they use
File Based or Scope Based tools, so although not ideal to either side,
acceptable until a suitable replacement could be forged.
* How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
Re-read SE-0025/proposal/most of this very long thread
From: <swift-evolution-boun...@swift.org> on behalf of Tino Heth via
swift-evolution <swift-evolution@swift.org>
Reply-To: Tino Heth <2...@gmx.de>
Date: Monday, March 27, 2017 at 6:48 AM
To: Zach Waldowski <z...@waldowski.me>
Cc: <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
I am now absolutely thrilled to create a filter to Mark As Read anything else
arising from this thread. Good luck.
That might be a good idea — after more than 200 messages, and a quite circular
discussion with an unhealthy amount of ignorance for the opposing side ;-).
To fight the latter, I just tried to take the position that "new private" is
really important, and this imho leads to interesting consequences...
This access modifier really doesn't solve a problem, like "let" does (unless
the problem you want to solve is having a language with private access).
Have a look at this:
public struct SeperateConcerns {
private var foo: Int = 0
public mutating func updateFoo(_ value: Int) {
print("The only allowed way to change foo was invoked")
foo = value
}
private var bar: Int = 0
public mutating func updateBar(_ value: Int) {
print("The only allowed way to change bar was invoked")
bar = value
}
private var foobar: Int = 0
public mutating func updateFoobar(_ value: Int) {
print("The only allowed way to change foobar was invoked")
foobar = value
}
}
You can protect foo from being changed by code in other files, and from
extensions in the same file — and if the latter is a concern, there should also
be a way to limit access to foo to specific function in scope.
Afaik, somebody proposed "partial" type declarations, but without them, the
meaning of private is rather arbitrary, and the feature is only useful for a
tiny special case.
If we had partial types, the situation would be different, and if would be
possible to declare extensions inside a partial declaration of another type, we
could even remove fileprivate without an replacement (I guess I should write a
separate mail for this thought…)
_______________________________________________ swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
