> On 14 Oct 2016, at 09:35, Jamie Lemon via swift-evolution
> <email@example.com> 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.
private by default is comparatively rare, it’s not true of Java, C#,
an enormous breaking change for Swift now.
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 mailing list