[swift-evolution] final + lazy + fileprivate modifiers

[Vladimir.S]

On 20.02.2017 18:25, Joanna Carter via swift-evolution wrote:
>
>> 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

Well, in general I support your opinion, but there is one question not 
answered by your 'extensible' modifier.
It is common to have access to type's internals in the same file from 
inside just other types("friend" types), not extending types.
So, in this case we want something like fileprivate+extensible if we want 
also share details for extending types in other files.
And so, IMO, 'extensible' should means 'accessible as for private but also 
in extending types AND INSIDE CURRENT FILE", or we need one more access 
modifier.

Also, there is a common(IMO) opinion in the list that we should rename 
fileprivate to private as in Swift2.

So, I believe this will be optimal minimum of access modifiers set:

public: outside of module
internal: anywhere inside module
private: anywhere in current file
scoped(hidden,*or other keyword*): as current 'private', only inside 
declared type
extensible : in current file and in subtypes/extensions in other files

>
> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>