<div dir="ltr"><div>Let's say I DON'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 "2 things vs 1 thing" argument is that it assumes that the subclassing has to happen in the first place.</div><div><br></div><div>I'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't necessarily "subclass and conform" it's "conform instead of subclass" - 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"><<a href="mailto:emaloney@gilt.com" target="_blank">emaloney@gilt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> On Mar 3, 2016, at 4:21 PM, Matthew Judge <<a href="mailto:matthew.judge@gmail.com">matthew.judge@gmail.com</a>> wrote:<br>
><br>
</span><span>> Not necessarily commenting for or against abstract classes, but the following logic confuses me:<br>
><br>
> "ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.<br>
><br>
> Protocols can't do this, because if you forget to declare conformance with the protocol, the compiler can't enforce anything. This pushes what could be caught at compile-time to a runtime (potentially crashing) problem."<br>
><br>
> 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's the difference between forgetting to do two things and forgetting to do just one.<br>
<br>
Let'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 "solution" 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>