[swift-evolution] final + lazy + fileprivate modifiers

[David Hart]

I don't agree with this point. I'm for a file-based private, but I definitely do NOT want access control eliminated, quite the contrary. I think the arguments are much subtle than what is presented here. I want strong access control, and to have that, the access control modifiers should be powerful and few do they are actually used. Right now we have private and fileprivate and many people don't use them consistently because they are so similar. We need only one private access control and I'm voting for fileprivate because it is the one which is the simplest while still working well with Swift's extension mechanisms.

On 20 Feb 2017, at 12:38, Joanna Carter via swift-evolution <swift-evolution at swift.org> wrote:

>> It's not that it's not meant to be called, but to be called from certain context. Coming back to a codebase after a while, you don't need to remember that method is not meant to be called out of certain context and if you name your methods well, you don't really need to go and take a look at what the method does, so you might miss this fact since you didn't go and read the docs. Xcode wouldn't even offer you this method in autocompletion if it were marked protected.
>> 
>> I'm not saying that this is something the Swift community can't live without, but it's of a huge convenience for newcomers to a project for whom the IDE wouldn't offer methods that should not get called from outside of the enclosing type.
>> 
>> I believe we are running to a point where the community is divided into two major camps - one part that would like to get the access control almost eliminated as they don't the see it that much useful; and second part that on the other hand would very much like to see extended access control - not by files/modules, but by the enclosing type. People are unlikely to switch these camps as their view on the subject is mostly shaped by their previous experience with working on team projects. 
>> 
>> IMHO, those who have previously worked with other experienced and responsible developers are probably advocates of less access control; those who have previously worked will less experienced developers are most likely pushing forward a more extended access control model.
>> 
>> I've previously worked as a lead developer in a few start-up businesses where people came and went and it was unnecessary burden to point to them why they shouldn't do something that way, that they overlooked that the member should not be invoked out of the enclosing context because they didn't full read documentation for that method; when you do this with a 10th person for the 100th time, you start wondering if this is one of those things that the language should help with a little by providing means of preventing people of misusing/abusing certain parts of the API.
> 
> Charlie, you really have hit the nail fairly and squarely on the head! :-)
> 
> It is all very well and good for experienced developers to say that others should read the documentation but, do you know what? After more than 25 years as a developer (including for languages that didn't have an IDE with autocompletion), I still rely heavily on autocompletion to help me through the morass that most frameworks ressemble.
> 
> The time saved be being able to see, at a glance, in the code that you are writing, what you can and cannot use, must run into years. Yes, I do look some stuff up in the UIKit and Cocoa source files and the documentation but that all takes time.
> 
> I have also worked as a lead developer, as well as a creator of frameworks and, as you rightly said, it is the inexperienced (or just darned lazy) developers who will not read anything other than that which autocompletion offers.
> 
> I once gave a task to such a developer, who then took three days to work out their own implementation of a small class hierarchy. When I pressed them to allow me to integrate their code, I found that it was incompatible with the rest of the system and was allocating memory in one file and deallocating it in another!
> 
> It took me half an hour to rewrite the whole thing from scratch.
> 
> The companies I have worked with don't want to have to allocate expensive resources like us to routine tasks. Autocompletion is an absolute godsend for both the inexperienced and experienced. Without good access control, enforced by autocompletion, reliable code takes longer to write and costs more.
> 
> --
> Joanna Carter
> Carter Consulting
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution