<div dir="ltr"><div>Let&#39;s say I DON&#39;T have a framework that requires me to supply a subclass of (class) Foo to do something useful, instead I have a framework that requires me to have my class conform to (protocol) Foo... my problem with your &quot;2 things vs 1 thing&quot; argument is that it assumes that the subclassing has to happen in the first place.</div><div><br></div><div>I&#39;m not convinced that using protocols in this way is a better solution than an abstract class, but as protocols develop the POP argument isn&#39;t necessarily &quot;subclass and conform&quot; it&#39;s &quot;conform instead of subclass&quot; - so 1 == 1</div><div><br></div><div>I do think that a proper evaluation of abstract classes cannot be done without examining what Swift would look like with protocols expanded to fill a similar role (which of the two approaches would add more complexity, which would be more powerful, etc.)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 3, 2016 at 4:26 PM, Evan Maloney <span dir="ltr">&lt;<a href="mailto:emaloney@gilt.com" target="_blank">emaloney@gilt.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>&gt; On Mar 3, 2016, at 4:21 PM, Matthew Judge &lt;<a href="mailto:matthew.judge@gmail.com">matthew.judge@gmail.com</a>&gt; wrote:<br>
&gt;<br>
</span><span>&gt; Not necessarily commenting for or against abstract classes, but the following logic confuses me:<br>
&gt;<br>
&gt; &quot;ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.<br>
&gt;<br>
&gt; Protocols can&#39;t do this, because if you forget to declare conformance with the protocol, the compiler can&#39;t enforce anything. This pushes what could be caught at compile-time to a runtime (potentially crashing) problem.&quot;<br>
&gt;<br>
&gt; What is the difference between forgetting to declare conformance to a protocol and forgetting to subclass an abstract class? An abstract class, ON ITS OWN, cannot force a class to do anything unless that class declares itself a subclass of the abstract class.<br>
<br>
</span>It&#39;s the difference between forgetting to do two things and forgetting to do just one.<br>
<br>
Let&#39;s say I have a framework that requires me to supply a subclass of Foo to do something useful.<br>
<br>
With abstract classes, I just need to subclass Foo, and the compiler tells me what implementations I need to provide.<br>
<br>
With the protocol-based &quot;solution&quot; being proposed, I need to subclass Foo *and* I need to remember to declare conformance to FooProtocol. Then and only then can the compiler enforce anything.<br>
<br>
2 != 1<br>
<br>
</blockquote></div><br></div>