<div dir="ltr">On Fri, Mar 24, 2017 at 10:57 PM, Jonathan Hull via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Mar 24, 2017, at 8:38 PM, Drew Crawford <<a href="mailto:drew@sealedabstract.com" target="_blank">drew@sealedabstract.com</a>> wrote:</div><div><p class="m_-7698795077478227574airmail_on" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On March 24, 2017 at 10:21:17 PM, Jonathan Hull (<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>) wrote:</p><blockquote type="cite" class="m_-7698795077478227574clean_bq" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span><div><div style="font-family:'helvetica Neue',helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">This is exactly the problem. Both for access controls and dispatch.</div></div></span></blockquote><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">How would you respond to clattner's <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html" target="_blank">position piece</a> on this? He disputes this point directly:</div></div></blockquote><blockquote type="cite"><div><div style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><blockquote type="cite" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-top-width:1px;border-right-width:1px;border-bottom-width:1px;padding-left:5px;border-left-width:1px!important;border-left-color:rgb(0,64,128)!important"><div>Swift is another case of a hybrid model: its semantics provide predictability between obviously static (structs, enums, and global funcs) and obviously dynamic (classes, protocols, and closures) constructs. A focus of Swift (like Java and Javascript) is to provide an apparently simple programming model. However, Swift also intentionally "cheats" in its global design by mixing in a few tricks to make the dynamic parts of the language optimizable by a static compiler in many common cases...</div><div>The upshot of this is that Swift isn’t squarely in either of the static or dynamic camps: it aims to provide a very predictable performance model (someone writing a bootloader or firmware can stick to using Swift structs and have a simple guarantee of no dynamic overhead or runtime dependence) while also providing an expressive and clean high level programming model - simplifying learning and the common case where programmers don’t care to count cycles.</div></blockquote></div></div></div></blockquote><div><br></div>I agree with him. I think you must be missing my point.</div><div><br><blockquote type="cite"><div><div style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="border-top-width:1px;border-right-width:1px;border-bottom-width:1px;padding-left:5px;border-left-width:1px!important;border-left-color:rgb(0,64,128)!important"><p>Is it? Can you point to an instance where a member of the core team said they are aiming for “plenty of overlap”?</p></blockquote><div><p>See above</p></div></div></div></blockquote><div>I don’t see where you are reading this from what he said.</div></div></div></blockquote><div><br></div><div>In fact, I read Chris's position piece as pretty clearly rejecting the "plenty of overlap" claim. An overlap would involve two or more things that have at least partly redundant function. Chris talks of a hybrid model: i.e., one thing, not two or more, melded from disparate parts in such a way that there is no overlap. His whole text is justifying the particular hybrid chosen. Offering both static and dynamic as two separate models is out of the question; the debate at hand is not _whether_ there should be one or two models in Swift, but _how_ two are to be combined into one.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><br><blockquote type="cite"><div><div style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div><blockquote type="cite" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-top-width:1px;border-right-width:1px;border-bottom-width:1px;padding-left:5px;border-left-width:1px!important;border-left-color:rgb(0,64,128)!important">Honestly, most of your examples could just be split into multiple files.</blockquote></div><p>Specific arguments were advanced in those examples that they cannot. Can you refute them?</p></div></div></div></blockquote><div>Honestly those felt like ill-advised hacks to me (especially shadowing in the same file). As Xiaodi suggested earlier, you could use a linter if you really wanted to enforce them. I personally use an underscore before variables I don’t want to expose outside the type.</div><div><br></div><div>I would be interested to know about other use-cases you have, because it may be possible to design for them in a way which does not require scoped private.</div><div><br></div><br><blockquote type="cite"><div><div style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div><blockquote type="cite" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-top-width:1px;border-right-width:1px;border-bottom-width:1px;padding-left:5px;border-left-width:1px!important;border-left-color:rgb(0,64,128)!important">You are conflating effort by the swift design and implementation community with your personal effort around migration.</blockquote></div><p>No, I am referencing a Swift@IBM developer who reported that </p><blockquote type="cite" style="border-top-width:1px;border-right-width:1px;border-bottom-width:1px;padding-left:5px;border-left-width:1px!important;border-left-color:rgb(0,64,128)!important">the open-source version of Foundation still has a long way to go to get the level of quality of the existing Objective-C frameworks, and we already have enough work to do without having to go make a bunch of arbitrary changes and risk a bunch of regressions because someone doesn't like a keyword... Accepting this proposal would waste hundreds of person-hours of work…</blockquote></div></div></div></blockquote>Yes you are. You can make a separate argument that migration will be an issue. (and if you recall my own vote was to wait on the implementation and make all of the changes at once in Swift 5).</div><div><br></div><div>I am asking about the time of the Swift team and surrounding design/implementation community. Do you honestly think that supporting both scope and file-based access control is important enough that we should spend the time/effort to fix the current issues in another way that allows both?</div><div><br></div><div>Thanks,</div><div>Jon</div><div><br></div><div><br></div><div><br></div><div><br></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>