<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=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2016-07-12, at 13:29, Jonathan Hull <<a href="mailto:jhull@gbis.com" class="">jhull@gbis.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">Note that most popular OOP languages provide well-known patterns for
creating sealed but public classes, where only the author is able to
create subclasses. These patterns typically involve hiding class
constructors from external modules. If Swift was changed to support
sealed classes the same way, would you then propose a language feature
to defeat access modifiers?</pre></blockquote><div class="">All I will say is that I avoid using those languages as much as possible. It is a separate topic, but in my opinion/experience languages which encourage too much planning/architecture lead to complicated programming structures (as an effort to work around limitations within the rules) and nothing of worth actually ends up getting accomplished. Give me smalltalk or objC any day.</div></div></div></div></blockquote><br class=""></div><div>There is truly nothing wrong with preferring the Objective-C/Smalltalk/Ruby/Python/JavaScript class of languages to the Java/C++/C#/Rust/Go camp. Most reasonable people would say that lots of worth has been accomplished in each of them. Also, most people would say that too little planning/architecture can be just as damaging (or more) as too much.</div><div><br class=""></div><div>But Swift is obviously in the second camp, and has been since 1.0.</div><div><br class=""></div><div>I doubt there is a good middle ground between the two approaches; they seem to be mutually incompatible. Most concessions to “loose" languages in a “strict” language feel out of place, and vice versa.</div><div><br class=""></div><div>Swift does provide an important concession to Objective-C in its @objc attribute, whose interaction with final/sealed classes could perhaps be tweaked to achive what you want.</div><div><br class=""></div><div>-- </div><div>Karoly</div>@lorentey</div></body></html>