<div dir="ltr">Without getting into a protracted argument, I just want to reiterate that:<div><br></div><div>* Foundation and Cocoa remain (and will remain for years) a critical part of Swift software development.</div><div>* These frameworks are built around inheritance hierarchies; what you can do to retrofit POP onto them is quite limited. If I want a partially customized UIView that makes changes through the existing API hooks I'm going to subclass, not create a protocol.</div><div>* These frameworks already contain classes and methods that are 'abstract', where that status is enforced through documentation or runtime asserts. This is, in my opinion, a hole that should have been filled a long time ago (but, for various technical reasons, couldn't); we have a chance now to do exactly that.</div><div><br></div><div>In terms of whether or not it's worth making changes to Swift et al 'just' to improve Objective-C interop...I think the community has pretty much decisively come down on the side of yes (see: typed selectors, importing of user-defined Objective-C generics as Swift generics, systematic renaming of imported Objective-C method names to conform with Swift compatibility...).</div><div><br></div><div>Austin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 3, 2016 at 12:55 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Mar 3, 2016, at 12:42 PM, Evan Maloney <<a href="mailto:emaloney@gilt.com">emaloney@gilt.com</a>> wrote:<br>
><br>
> There has been a proposal floated (by Dave Abrahams if I recall--and if I'm wrong, sorry!) to change protocols so conformance is NOT inherited by subclasses by default.<br>
><br>
> I would just like to point out that if that happens, all of the arguments against abstract classes go out the window, and we absolutely WILL need abstract classes, because all the convoluted gymnastics required to get protocols to kinda-sorta (but not really) provide some of what abstract classes provide won't be possible.<br>
><br>
> Long live the class hierarchy!<br>
<br>
</span>That was me. I only proposed it as an *option* for the conformer, though, not as a sweeping change.<br>
<br>
-Joe<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>