> On 27 Mar 2017, at 16:46, Steven Knodl via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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.
Right. I do that myself more than I would like to admit.
But when we only loosen up/tighten down during coding then access levels are
almost useless.
The point of access level control is in the design, not in the coding.
If we made a design (including access levels) and then have to dial back, that
should be a warning that something is wrong.
To me, this is an argument in favour of the proposal.
Rien.
> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
