<div dir="ltr">@Brandon<div><br></div><div><div style="font-size:12.800000190734863px"><i>Is anyone starting to think the current access control model will become more burdensome over time?</i></div><div style="font-size:12.800000190734863px"><i><br></i></div><div style="font-size:12.800000190734863px"><i>People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern language. </i></div><div style="font-size:12.800000190734863px"><i><br></i></div><div style="font-size:12.800000190734863px">.Most definitely. We've mentioned earlier in this thread the usage of file private feels somehow we're basing swift design on compiler related constructs. </div><div style="font-size:12.800000190734863px"><i><br></i></div><div style="font-size:12.800000190734863px"><i>For example, fileprivate and private encourage stuffing a lot of code into one file just to use that access control level. If you want to break this into more manageable chunks you have to make it internal or move it into a new module which is very complicated to do in Xcode (I.e requiring a new target like a framework). </i></div><div style="font-size:12.800000190734863px"><i><br></i></div><div style="font-size:12.800000190734863px"><i>.</i>Agreed. As stated before, this might lead into some kind of pattern where types are chunked into the same file for the sakes of member access convenience. I strongly believe we should aim at promoting code clarity and readability while enhancing single responsibility principle's good practices.</div><div style="font-size:12.800000190734863px"><i><br></i></div><div style="font-size:12.800000190734863px"><i>This keeps leading me back to having submodules or creating modules on demand. I think that would open up this system to great complexity.</i></div><div style="font-size:12.800000190734863px"><i><br></i></div><div style="font-size:12.800000190734863px"><i>Want to keep something private to a specific class but private to anything outside of it? Make it internal to the same "submodule". </i></div><div style="font-size:12.800000190734863px"><i><br></i></div><div style="font-size:12.800000190734863px"><i>I think we could keep tacking on things to access control, but I don't think it is really solving everyone's needs. I think a more flexible system would allow people to adapt it to their needs instead of structuring everything around a rigid system that forces you to do it swift's way. </i></div></div><div style="font-size:12.800000190734863px"><i><br></i></div><div style="font-size:12.800000190734863px">Don't you feel that would defeat the purpose of access control levels? Correct if I'm wrong, but I don't think there's much to gain from trying to dodge the need for private (whether scope private, fileprivate or eventually typeprivate) members no matter how modularised your code is. Also, I believe it an unworthy effort, as I think we could run the risk of creating problems further in the chain of access control levels? I just think we'd be pushing the problem further up the hill.</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px">Best,</div><div style="font-size:12.800000190734863px">Gonçalo</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-01 20:40 GMT+00:00 Brandon Knope <span dir="ltr"><<a href="mailto:bknope@me.com" target="_blank">bknope@me.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> This keeps leading me back to having submodules or creating modules on demand. I think that would open up this system to great complexity.<br>
<br>
</span>I meant "flexibility"...not complexity. Freudian slip? 😂<br>
<span class="HOEnZb"><font color="#888888"><br>
Brandon </font></span></blockquote></div><br></div>