[swift-evolution] private & fileprivate
jeremy.j.pereira at googlemail.com
Fri Oct 14 09:59:42 CDT 2016
> On 14 Oct 2016, at 09:35, Jamie Lemon via swift-evolution <swift-evolution at swift.org> wrote:
> I agree with Ted that I would have expected the inner members of a class to be private by default. (Not a big deal if I have to explicitly prefix most of my concerned vars now - but it is just different to what I would have expected). Certainly, in the past, I would be more used to having to explicitly define chosen vars as “public” ( e.g. in the past world of Objective C I was used to defining selected vars with @synthesize to “open them up" )
@synthesize has nothing to do with instance variable visibility, all it did was synthesise an instance variable to back a property (which was really a pair of methods). In Objective-C instance variables are protected (i.e. visible to subclasses) by default and all methods (which by extension means properties too) are public.
The waters are somewhat muddied by the fact that the Objective-C compiler can only see declarations in the current code unit and any imports, so you can hide non private instance variables by putting them in the @implementation and you can hide properties and methods by declaring them in a category that isn’t in an import. However, anybody can defeat the second of these by declaring their own category with the hidden method signatures in it.
I was against the private/fileprivate distinction when it was proposed, but now it’s done and I’ve applied it to my own code, I am fine with it. I did a global replace of fileprivate with private in one of my largest converted source files and experienced only one breakage. I think there is a use case for fileprivate, so I wouldn’t want to get rid of it but I think it’s rare enough that the ugliness of its name doesn’t bother me.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution