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@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@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
