Access levels are not a security mechanism. You have to trust your (fellow) programmers. Lots of good software has been created in Smalltalk and other languages without "private" access levels.
-- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace.blogspot.com/ > On Oct 30, 2017, at 5:34 AM, Mike Kluev via swift-evolution > <swift-evolution@swift.org> wrote: > >> On 30 October 2017 at 07:30, Adam Kemp <adam.k...@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 > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
