Re: [swift-evolution] final + lazy + fileprivate modifiers

Fri, 17 Feb 2017 09:22:54 -0800 


Sent from my iPhone
> On Feb 17, 2017, at 01:02, Rien <[email protected]> wrote:
> 
> 
>> On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution 
>> <[email protected]> wrote:
>> 
>> 
>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> While we’re bikeshedding, I’m going to add my two cents. Hold on to your 
>>> hat because this might be controversial here.
>>> 
>>> I think both ‘private’ and ‘fileprivate’ are unnecessary complications that 
>>> only serve to clutter the language.
>>> 
>>> It would make a lot more sense to just have internal and public only. No 
>>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>> 
>> Eh, I've used `private` to keep myself honest in terms of going through some 
>> book-keeping functions instead of directly accessing a property.
> 
> But is that not an argument to get rid of ‘private’ & ‘fileprivate’?
> 
> With great power there comes great responsibility ;-)

I don't see how... I used `private` on some dicts that interact with each other 
(faking a lightweight database) to ensure I was using my type's subscript 
functions (which handle updating all the dicts correctly) instead of directly 
accessing the dictionaries in some areas where the interactions theoretically 
wouldn't matter. Since I was able to mark those properties as private, I know 
that all the access to those properties goes through the proper book-keeping 
functions. Not only does this reduce the opportunity for bugs, it makes it far 
simpler to change the implementation later if I decide it should be backed by a 
"proper" database since everything that directly touches the storage will be 
right there in the type definition instead of spread through however many 
extensions across however many files.

- Dave Sweeris 
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution





























					Reply via email to