> Was surprised that you expressed exactly what I'm thinking about this subject. > > I do believe even in Swift we need a way to say "only code that *knows* what > it does should see this" and to not force us to write(and manage) the the > code in same file. > Yes, some implementation details that shouldn't be used by "users" of the > type, but can be used by "extenders" of our type. At least in the same module.
Indeed. I spent a number of years designing and implementing a very large framework (in C#) for a company who had a small team of developers of varying skill levels and, whether they were working on the framework or on the app that used the framework, the number one consideration had to be ensuring that they were not able to break something that was already tested and approved, inadvertently, whilst working on another part of the project. this was especially relevant to work being done on classes that derived from base classes or classes that implemented interfaces (protocols). With the present state of Swift, I would not be as confident handing out such tasks to a team using this language. > While reading, the question was raised(if was discussed, let me know pls): > what if we extend the meaning of 'private' to 'visible to current type/scope > and subtypes and extensions in the *same module*' ? > This will help us to split types by files, help to better model access policy > for fields/methods(i.e. only scope that can know about details can see them) > while 'private' still will be hidden outside of the module even for > subclasses/extensions. Hmm. I really don't like the idea of extending private to mean anything other than inside the declaring scope. I was one of those who was disappointed with the Swift 2 definition of it being file scope, having seen the abuse and generally bad code that developers fall into when allowed that freedom. In Delphi, I have seen some horrendously large files that contained everything but the kitchen sink ; when I asked the developer why he had done it, he said it was because, otherwise, he couldn't access the private members of a base class (he didn't understand the concept of protected visibility 8-) > Actually I still believe we need current 'private' and additionally some > 'protected' with meaning "access from subtype, or extension" probably with > this limitation: "only in the same module". But suggested extended 'private' > will be also OK for me. And this is where I find myself. My suggestion was to try to integrate the idea of "protected" within class hierarchies with the need for privileged access for extensions to other types, whether they be in the same module or not. Hence the name "extensible" to signify whether you were extending a class by inheritance or any other type with an extension, we would only need the one keyword to clearly express the concept. -- Joanna Carter Carter Consulting _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
