[swift-evolution] final + lazy + fileprivate modifiers

Joanna Carter joanna at carterconsulting.org.uk
Mon Feb 20 05:38:06 CST 2017

> 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

More information about the swift-evolution mailing list