<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">> * What is your evaluation of the proposal?<div class=""><br class=""></div><div class="">I’m on board with solving the problems outlined here. In particular, continuing to make Swift safe and fast by default and extending access and features as needed. And I am mostly on board with the solution proposed here.</div><div class=""><br class=""></div><div class="">I have 2 big concerns:</div><div class=""><br class=""></div><div class="">1) Unlike most changes to the language, the problems from this change will not be immediately evident. While a module author typically uses their module in at least 1 project of their own, they don’t see the usage point for most of their API. This change will likely cause a long process of updates for modules going back and forth between updating the module and the app that uses it.</div><div class=""><br class=""></div><div class="">2) As the proposal is written, we are introducing 2 new terms into the language that are not that different from what we already have (final and public/internal/private). I would really like to see these terms merged to limit the vocabulary of the language. Personally I am in favor of public(<span style="font-family: Menlo; font-size: medium;" class="">extensible</span>) for both classes and methods.</div><div class=""><br class="">> * Is the problem being addressed significant enough to warrant a change to Swift?</div><div class=""><br class=""></div><div class="">Yes. In particular, giving the language the ability to fine tune what can and cannot be overridden is very helpful.</div><div class=""><br class="">> * Does this proposal fit well with the feel and direction of Swift?</div><div class=""><br class=""></div><div class="">Yes. The biggest argument I’ve seen against this behavior is that we need to be able to fix Apple’s frameworks for them. But the direction of Swift is away from doing this (having final available at all, no method swizzling etc.) and for good reason.</div><div class=""><br class="">> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div><div class=""><br class=""></div><div class="">There was an interesting discussion somewhat related to this on the latest Bike Shed (<a href="http://bikeshed.fm/70" class="">http://bikeshed.fm/70</a>) coming from the perspective of Ruby developers.</div><div class=""><br class=""></div><div class="">> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div><div class=""><br class=""></div><div class="">I’ve read through the final proposal and have also given it occasional thought over the weeks building up to the proposal. I’ve also read a handful of responses.<br class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; border-spacing: 0px;"><div class=""><br class="Apple-interchange-newline"><b style="font-size: 18px;" class="">David Beck</b></div><div style="font-weight: normal;" class=""><a href="http://davidbeck.co" class="">http://davidbeck.co</a></div><div style="font-weight: normal;" class=""><a href="http://twitter.com/davbeck" class="">http://twitter.com/davbeck</a></div><div style="font-weight: normal;" class=""><a href="http://facebook.com/davbeck" class="">http://facebook.com/davbeck</a></div></span></div>
</div>
<br class=""></div></body></html>