Brent, You make a very good point about the fact internal is not necessarily the same as subclass, something I hadn’t considered.
I think that the level of exposure these APIs then get - ultimately Public within frameworks - is too unrestricted. At least in Objective-C, we can vet the headers to break classes into separate sections where we don’t disclose certain headers to show something by default. Can we think of a way to allow opt-in access? This ultimately gets into one of my major sore points with Swift: Framework Generated Headers suck. The Framework story for Swift seems shockingly ill conceived at this time. I could never imagine Apple shipping a framework with the current Framework setup… but I’m going into the weeds... -Rod > On 30 May 2016, at 10:03 AM, Brent Royal-Gordon <[email protected]> > wrote: > >> 1. Methods and properties that only subclasses must access, but other code >> has no business updating. An example of this UIGestureRecognizer. State >> machine type access is something where external items should not access, but >> internal state may require the rights to update. > > But again, "external" does not necessarily mean "non-subclass", and > "internal" does not necessarily mean "subclass". A particular subclass might > not require access, and a helper type/function might require access. > > This insight—that the type graph doesn't always reflect the boundaries of > concerns—is the very basis of Swift's current access control design. It's the > reason why `private` (soon to become `fileprivate`) doesn't grant visibility > to extensions on the same type in different files, but *does* grant it to > extensions on different types in the same file. This is an important > innovation in Swift's access control design, and we shouldn't ignore it when > we're thinking about `protected`. > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
