[swift-evolution] [Proposal] Protected Access Level

[L Mihalkovic]

> On May 30, 2016, at 2:46 AM, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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…

most Objc code out there is appalling when it comes to design enforcing clean API boundaries. It stems directly from the lack of scopes in the language to hide things. Over the years the language was drastically improved, but 99% of the code on github is still written like 20 years ago (minus the @synthesize). Unfortunately for swift, there is not much more choices than to have Framework = Module. A possible future improvement might be to have Framework = n-Module, but that is somehow doable if you make a multi dylib framework. The cost of creating several Swift modules inside a single framework is not light today (there would have to be one more level of section name mangling inside the dylib, something like  

	__xxxx__sectionA 
	__xxxx__sectionB 
	__xxxx__sectionC 

	__yyyy__sectionA 
	__yyyy__sectionB 
	__yyyy__sectionC 

where xxxx/yyyy are the names of the modules/namespaces sharing space inside a single dylib, compared to today's

	__sectionA 
	__sectionB 
	__sectionC 

all things considered, it may not be that stupid… dunno it is would make lookup faster or slower if the sections were smaller. It would be backward compatible… because the current sections could be kept for the top level Module… hmmmmm… might be workable.

> 
> -Rod
> 
> 
>> On 30 May 2016, at 10:03 AM, Brent Royal-Gordon <brent at architechies.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution