<div dir="ltr">From the other thread, quoting myself:<div><br></div><div>&quot;<span style="font-family:&#39;Helvetica Neue&#39;;font-size:13px">Do not take me wrong, I really like protocols and structs and I understand how to use them, but it seems that many of us believe that the is something wrong with classes and the protocol/struct is the new Holy Grail. I disagree. New possibilites and new way to do things are always welcome, mainly if they are solid and consistent and really solves the problem intended to be solved.</span></div><div style="font-size:13px"><font face="Helvetica Neue"><br></font></div><div style="font-size:13px"><font face="Helvetica Neue">I also understand that the Swift team does not want to introduce any new keywords to the language. </font>To tell the truth I think I need to read again all the information on Swift. I thought the Swift would be one thing, but looks like it will be another. It is likely that the wrong one is me.</div><div style="font-size:13px"><br></div><div style="font-size:13px">Provide ways to create abstract classes and abstract methods is not a &quot;keystroke saver&quot;. It is one of many concepts involved in OOP, IMHO.&quot;</div><div style="font-size:13px"><br></div><div style="font-size:13px">-Van</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 4:21 PM, Sean Heber via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Proposal link:<br>
&gt;<br>
&gt; <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md</a><br>
<span class="">&gt;       • What is your evaluation of the proposal?<br>
<br>
</span>I am mixed on this. I’ve mentioned wanting this myself on this list and have run into situations where I *really* wished I had it at the time (instead of having to do fatalError()), but ultimately I’ve almost always gone back to redesign those things to get rid of the abstract base class pattern and improved the design in the process. Perhaps this is an anti-pattern and Swift should not encourage it. I’m not sure.<br>
<span class=""><br>
<br>
&gt;       • Is the problem being addressed significant enough to warrant a change to Swift?<br>
<br>
</span>I’m not so sure. I feel like by not having it, Swift has often pushed me toward better design (at the cost of some of my hair).<br>
<span class=""><br>
<br>
&gt;       • Does this proposal fit well with the feel and direction of Swift?<br>
<br>
</span>Again, I’m not sure about this. I don’t think the potential of protocols have been fully explored yet and this feels like just adding an old feature from old languages because that’s the way we’re used to doing it. I feel like you could get the same effect by having a way to apply a single protocol to a class “abstractly” and have that *result in* an abstract class. This would more clearly separate the parts that are meant for subclasses to fill in vs. not. For example, to use the class from the proposal:<br>
<br>
protocol RESTClientSubclass {<br>
  var url : String { get }<br>
}<br>
<br>
class RESTClient: @abstract(RESTClientSubclass) {}<br>
<br>
class MyRestServiceClient : RESTClient {<br>
  var url : String { return &quot;<a href="http://www.foo.com/client" rel="noreferrer" target="_blank">http://www.foo.com/client</a>” }<br>
}<br>
<br>
“override” wouldn’t be necessary here because you’re not actually overriding anything and the methods/properties the subclass needs to implement are clearly grouped together in the RESTClientSubclass protocol. (In fact it might even be an error for RESTClient to implement *any* method itself in an abstract protocol conformance).<br>
<span class=""><br>
<br>
&gt;       • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
<br>
</span>Yes and it doesn’t feel any different - which is what bothers me, perhaps. :)<br>
<span class=""><br>
<br>
&gt;       • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
</span>Skimmed the discussions as they happened a bit, read the proposal, but did not spend significant time on it.<br>
<br>
l8r<br>
Sean<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<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>