[swift-evolution] classprivate protection level?

[Mike Kluev]

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
file



> Which other language has an access level like the one being proposed?
>
>
> this:
>
> 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 :-)
>
> Mike
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171030/2435bf9a/attachment.html>