[swift-evolution] classprivate protection level?
Mike Kluev
mike.kluev at gmail.com
Mon Oct 30 07:34:46 CDT 2017
On 30 October 2017 at 07:30, Adam Kemp <adam.kemp at apple.com> wrote:
>
> No. There are two reasonable options:
>
> 1. Make it public. If it’s needed outside the module then this is an
> accurate description of its access level.
>
> 2. Make it internal and accept that any code in the same module can access
> it. Again, that is effectively what your proposed scope allows anyway so
> internal is an accurate description of its actual access level. Call it
> what it is.
>
>
Adam, i fail to see why you say "No" to "one module per class approach" if
the goal is to make the individual multi-file classes as isolated as
possible (i.e. not see each other "internal" stuff). which (this goal) is
considered the "way to go" approach in other languages and the "default"
behaviour.
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/89a2bbc5/attachment.html>
More information about the swift-evolution
mailing list