On 30 October 2017 at 16:34, Adam Kemp <[email protected]> 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 > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
