> On Apr 8, 2017, at 5:19 AM, Neil via swift-evolution > <[email protected]> wrote: > > I agreed with Charlie, but I think there’s another option. > > The access control problems that both SE-0159 and SE-0169 are attempting to > address can be resolved not by changing the definition of the existing access > modifiers, but refocussing the use of extensions. > > One such way would be to introduce a `partial` modifier. It would be similar > to C#’s partial modifier. The proposed partial modifier would be purely > additive and it would go a long way to mitigate the access control issues > inherent in extension-oriented design. > > The key characteristics of partial-oriented design would be: > > - Partials would allow the splitting of implementations into multiple logical > units without the same-file restriction.
I really like the idea of partial but it would need to be restricted to the same file. This would allow partial to just be a compile time feature which just zips up a type together. Another great feature would be that it could allow stored properties because it is only a compile time feature. Partial could be used to communicate to the user that this type has additional members and properties declared somewhere else in the file. +1 for file scope partial. > - Partial definitions of a type are restricted to same module. If you wish to > add functionality to a type external to its defining module, use an > extension. > - Partials would provide greater clarity between additive extension and the > original implementation. > - Within a partial, private would be type-private. > - Within an extension, private would be scoped-private (the status quo). > > I do see that the last two points may introduce some friction. Particularly > because: > > - Within a partial, fileprivate would be more restrictive than private. > - Within an extension, fileprivate would be less restrictive than private > (the status quo). > > However, I don’t see these as too challenging for educators or developers as > they are differentiated by their top-level scope. > > >> On 07/04/2017, 05:57, "Charlie Monroe via swift-evolution" >> <[email protected] on behalf of [email protected]> >> wrote: >> >> Simply as long as it's file-based, it's not a solution, it's just another >> attempt to satisfy some part of the community. I'm not saying that the >> current access levels are perfect, but I still believe the way to go is to >> either use submodules, and/or introducing the concept of "protected" members. > > > > > > > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
