[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[João David]

Definetely the access control topic is highly contestable in the Swift scene but nevertheless I really strive for more flexibility in terms of how can I decouple and decompose my code arch among several source files.
As an example, I reckon that the current approach of attributing properties with fileprivate is somehow encouraging developers to workaround patterns like "protected" accessors into padding files with endless classes hierarchies and that’s one of the main reasons why I’m agains’t this fileprivate access modifier in the first place.
To sum up, I really strive for code with great encapsulation and this proposal is for sure marching in that direction.

If we can add extensibility to classes without break fundamental encapsulation rules while doing it in a organised way, without stuffing file sources with the whole class spectrum, we have a winner in my opinion.


> 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/master/
> proposals/NNNN-introduce-typeprivate-access-control-level.md
> 
> Thanks in advance for taking the time to evaluate the proposal.
> 
> Best regards,
> Gonçalo
> 
> 
>  

João David
iOS Software Architect
LinkedIn <http://pt.linkedin.com/in/joaotdavid> | +351 933631927 | Skype: joaotdavid

Please visit the iSOPARC <http://ciafel.fade.up.pt/isoparc> and iSOFIT <http://ciafel.fade.up.pt/isofit> for iPad application website.









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161130/c37261b1/attachment.html>