<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=""><br class=""><div class=""><div class=""><div class="">I completely agree. We have the final keyword for that, ensuring that if I do not plan for it to be subclassable, it cannot be.</div><div class=""><br class=""></div><div class="">The question here is not “should a framework author be able to block a developer from subclassing?” but “Should I assume it is, or is not, subclassable?"</div><div class=""><br class=""></div><div class="">I err on the side of flexibility. Others err on the side of simplicity and safety.</div></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 Dec 2015, at 1:30 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div class=""><br class=""></div><div class="">Legitimacy is in the eye of the beholder. I think it is quite legitimate for a framework author (especially the platform vendor) to decide what you can and cannot do with their framework. </div></div></blockquote></div><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">When I hear about code in Apple’s frameworks that is responsible detecting and working around inappropriate uses of their frameworks it makes me cringe. Anything that helps to remove the need for this in the long run is a really great thing. </div></div></blockquote></div></div></body></html>