[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Rudolf Adamkovic]

-1 from me.

Using extensions for "code organization" is another word for writing spaghetti code.

It results in types with many responsibilities. In such cases, it's time to extract collaborator types.

But it sure looks prettier.

R+

Sent from my iPhone

> On 7 Apr 2017, at 10:56, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> What is your evaluation of the proposal?
> 
> Strong -1.  Just rename ‘fileprivate’ to be less annoying.
> 
> This proposal will make things even worse than they are currently.  We will regret it just as much, if not more than, 0025.  As others have mentioned, it is actively harmful:
> • It once again changes the meaning of private
> • It takes away most of the actual power of private (vs fileprivate). (I was for returning to the simpler Swift 2 access, but when I did use private, I used it to limit access to just a few lines of code. This proposal gets rid of the last ounce of usefulness of ‘private’ for me, and only has the virtue of a less annoying name).
> • It is the camel’s nose in the tent for type-based access (people will ask for future versions to be available in the type in the submodule, module, and then public… but we will be unable to give it to them)
> • It breaks the same code that 0159 would have broken
> • It will be a nightmare to teach/learn
> 
> Also, the idea that we should limit the use of ‘fileprivate’ is incorrect. Fileprivate is the best access levels for a lot of cases, it just has an annoying name.  Given our constraints, I now believe the only sane choice left to us is to make fileprivate easier to use (as opposed to making private more like it) and to get rid of the cognitive dissonance of having similar names/concepts by renaming ‘fileprivate’ to something like ‘local’.  ‘fileprivate’ (whatever it is called) should be the soft-default. ‘private’ should be the one being used explicitly.
> 
> We are likely going to have to rename ‘fileprivate’ anyway to work with submodules (that or add another access level), and ‘local’ has connotations of visible nearby… so I think it works well enough.
> 
>> Is the problem being addressed significant enough to warrant a change to Swift?
> Yes, access controls are a mess… but this will make them more of a mess.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> No.
> 
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> No. I have used languages with type-based private, and I have used languages with file-based private… but never type-based that was limited to a file.  You got shrimp in my chocolate (not all great tastes go well together).
> 
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> I have followed the discussion closely and spent a great deal of time thinking about it.
> 
> Thanks,
> Jon
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20170416/59907623/attachment.html>