> 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. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
