[swift-evolution] final + lazy + fileprivate modifiers

[Joanna Carter]

> Le 20 févr. 2017 à 15:30, Dimitri Racordon <Dimitri.Racordon at unige.ch> a écrit :
> 
> I think that fileprivate is fine, and that the drawback of having very large files is acceptable,

Having had to debug code for my clients in past years, I can say that, from real world experience, large code files are a $&§*% nightmare.

They are an absolute dog to maintain if you are working in a team environment because, if one person wants to work on one extension and another wants to work on a second, the source control implications are horrendous with merges, conflicts, etc, all over the shop.

Of course, if you are a lone developer, then it's up to you how long you take to find bugs and fix them and, as for source control, there is no problem with all those merges and conflicts. Just spare a thought for the larger teams.

> compared to additional complexity induced by more subtle access control syntax/semantics. fileprivate has the privilege to be easy to understand by *anyone*; extensible, scoped, protected and the likes are not.

Most developers who any experience in any OO language other than Objective-C and Swift are usually extremely well versed in the "standard" class visibilities ; it's one of those things you get taught in the first couple of lectures on any good programming course.

> Also, I don’t think the expressivity of access control should cover every single case:
> * What if I want another type to access my internal properties?

Use 'extensible' on the properties you want to expose

> * What if I want another type to access a subset of my internal properties?

Use 'extensible' on the properties you want to expose

> * What if I want another type to access a subset of my internal properties in read-only?

Use 'extensible' on the properties you want to expose

> * What if I want another *function* to access my internal properties?

Use 'extensible' on the properties you want to expose

Ah, hang on, that makes…  one visibility to learn ;-)

> I may even agree that in these instances a super-fine-tuned access control might have saved few hours of work, but nobody seem to consider the additional cost of having those in the first place. If it takes days for (in)experienced users to understand the meaning of an access control modifier,

private - only accessible in the declaring entity
extensible - accessible as for private but also in extending types
internal - accessible anywhere within a module
public - accessible anywhere

You really think it takes days to learn four visibilities? I am truly shocked!

> plus hours and hours of debating with your team whether some type/function/property should be private, file private, type private, extensible private, module private, etc. the potential time saved by having access control is lost by having to define it properly.

Of course, if you only use the above four visibilities, the discussions are much shorter ;-)

--
Joanna Carter
Carter Consulting