Hey, Robert! Thanks for your feedback.
I do believe that it is a common practice, and a good one as well, to have your code broken down into separate extensions, either for improving code readability by reducing the size of the implementation file, as well as creating context for feature development. Also, I do agree that one should have separate classes, structs, enums or whatever better fits the purpose, handle code regarding a single responsibility. However, should this responsibility remain within the scope of the type we're implementing it on, it's best to have the code split into separate extensions on separate files (so to avoid large and hard to inspect files), and have these extensions access members which, would *no longer* *be visible* to the whole module. I do believe, having these members marked as *internal* creates the conditions for one to *scatter* and *decompose *a type since it opens the door for type in the module to lay hands on it's members. *Typeprivate* would prevent these members to be accessed from everywhere in the module, while enabling them to be reached from everywhere within their type. Also, I believe that having the scope of a member limited by file scope does does fall short in fitting a language design purpose, as file is a compiler related construct which could, in turn, be replaced somewhere in time, thus leaving the “fileprivate” access member orphaned. Best, Gonçalo 2016-11-29 16:13 GMT+00:00 Robert Widmann <devteam.cod...@gmail.com>: > Is that a particularly common case? I haven’t written code that needs > access patterns like this and it strikes me as strange that anything you’re > willing to expose to extensions scattered throughout your codebase you’d > also prefer not to export throughout a module that you have complete > control over. Sure, it might be “cleaner” to scope your variables to the > implementation, but past a certain point it just seems to encourage extreme > decomposition and scattering of a single class or structure when you should > be separating your implementation into multiple classes and structures. > > On Nov 29, 2016, at 11:07 AM, Gonçalo Alvarez Peixoto < > goncalo.alvarezpeix...@gmail.com> wrote: > > Robert, > > Thanks for your feedback. > > However, I tend to disagree with you. > > *"The proposal, as it stands, does nothing to indicate how this is much > different from internal - all examples given would trivially be solved by > internal members."* > This proposal aims at covering all of the cases in which you *do not want* to > expose your properties *internally. *For instance, you might want to > access a member of a view controller from an extension of this view > controller on another file, but not make it accessible from other members > in the module (which is what *internal *does). > > Best, > Gonçalo > > 2016-11-29 15:53 GMT+00:00 Robert Widmann <devteam.cod...@gmail.com>: > >> The proposal, as it stands, does nothing to indicate how this is much >> different from internal - all examples given would trivially be solved by >> internal members. I don’t think we need finer-grained access control to >> address this, I think we need extensions, at least in the same file as >> their parent declarations, to be able to define variables. >> >> On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello, everyone! >> >> I would like to introduce a new proposal to swift evolution, but first I >> would love to run it by all of you so I get everyone's feedback and enrich >> it. >> >> This proposal consists of introducing a new *typeprivate *access control >> level which allows for members to be accessed in all extensions of a given >> *type,* whether lying within or in another file. >> >> You'll find the proposal draft in: >> https://github.com/goncaloalvarez/swift-evolution/blob/maste >> r/proposals/NNNN-introduce-typeprivate-access-control-level.md >> >> Thanks in advance for taking the time to evaluate the proposal. >> >> Best regards, >> Gonçalo >> _______________________________________________ >> 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
