[swift-evolution] final + lazy + fileprivate modifiers
Dimitri.Racordon at unige.ch
Mon Feb 20 09:59:28 CST 2017
> Having had to debug code for my clients in past years, I can say that, from real world experience, large code files are a $&§*% nightmare.
This is what I meant when I said that everybody has a story about that time it was so hard to do this because of that. This is not to say that I don’t want to spare a thought for people in large teams. I do recognise the issue, I just don’t think complicated access control is the silver bullet. Hence I’d rather favour simplicity of the language over expressivity of its access control.
If ill-advised users want to do silly things with your awesome type, they will. I’ll bet we could find one person who thinks using reflection is such a clever way to bypass these so-called private properties.
> Most developers who any experience in any OO language other than Objective-C and Swift are usually extremely well versed in the "standard" class visibilities ; it's one of those things you get taught in the first couple of lectures on any good programming course.
Yet if you google "private vs protected", the first 5 links are stackoverflow questions on the subject, and the rest of the first page are blog posts like “Pragmatism over Theory: Protected vs Private”. Despite decades of OO, those notions are still confusing for many people, and are intimidating for newcomers.
Besides, I think those results also illustrate my point about the time-consuming debates on what access level something should have.
> Ah, hang on, that makes… one visibility to learn ;-)
Nope, it doesn’t. Extensible wouldn’t restrict the visibility as tightly as I described. That said, that list was a shameless exaggeration more than a critique of your proposition.
More information about the swift-evolution