[swift-evolution] classprivate protection level?
mike.kluev at gmail.com
Mon Oct 30 12:10:08 CDT 2017
On 30 October 2017 at 16:34, Adam Kemp <adam_kemp at apple.com> wrote:
> I didn’t mean “no, you can’t do that”. You can if you want to. What I
> meant was “no, I’m not suggesting that you should do that”. I don’t think
> it’s necessary.
as you said before the benefit of keeping private things private is
minimizing the amount of code that can break once you change a variable. if
it's "internal" - the whole module must be checked. if it is "internal"
rather than "private":
it is done because otherwise i'd have to keep the (big) class in a single
> Which other language has an access level like the one being proposed?
> SingleFileClass1.swift // with bunch of "privates" inside
> SingleFileClass2.swift // with bunch of "privates" inside
> SingleFileClass3.swift // with bunch of "privates" inside
> is equivalent to this:
> Module solely for Class1
> Class1.swift // with bunch of "internals inside
> Class1+Extension.swift // with bunch of "internals" inside
> Module solely for Class2
> Class2.swift // with bunch of "internals" inside
> Class2+Extension.swift // with bunch of "internals" inside
> Module solely for Class3
> Class3.swift // with bunch of "internals" inside
> Class3+Extension.swift // with bunch of "internals" inside
> still "no" ?
> i mean, it's fine (although a bit odd) that a mere change from a
> single-file to a multi-file class leads to such drastic consequences.
> different to what i saw before. but I can adapt of course.
> Either way the answer is basically the same: don’t obfuscate the effective
>> access level and pretend you’re being strict when you’re really not. It’s
>> like putting a lock on the door with the key hanging from the doorknob. You
>> may as well just keep it unlocked.
> nice analogy :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution