<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="">I agree that abstract classes/methods are useful and probably belong in Swift. Inheritance is still (in my opinion) the most natural way to model certain problem domains, even if it has been falsely touted as a panacea for far too long, and I feel like its inclusion in Swift is more than just a sop to Objective-C interoperability.<div class=""><br class=""></div><div class="">Practically speaking, iOS/OS X GUI applications written using Apple's existing frameworks are going to be a major part of Swift's future for a long time to come, and the ability to define abstract classes is a natural fit for Cocoa, UIKit, and Foundation's inheritance-based paradigm. Abstract classes serve a purpose (e.g. abstract subclasses of UITableViewController intended to break out shared app-specific functionality) that protocol extensions can't fulfill. You can also go through the documentation and note the many classes which are intended to be subclassed (with mandatory extension points), but cannot express misuse to the programmer until they are used at runtime.<div class=""><br class=""></div><div class="">Austin<div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 11:22 PM, Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 7 janv. 2016 à 20:41, Charles Constant via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">> <span style="font-size: 13px;" class="">I am not sure that the language should discourage a feature it supports and impose friction on it because it could be abused.</span><div class=""><span style="font-size: 13px;" class=""><br class=""></span></div><div class="">Especially since the OOP philosophy is falling out of fashion anyway. Thousands of CompSci profs, and programming blogs, all saying "we've come to our senses, OOP is confusing". Adding Abstract classes to Swift isn't going to turn that ship around.</div></div></div></blockquote><br class=""></div><div class="">It’s not only about fashion, is it?</div><div class=""><br class=""></div><div class="">Let’s take a practical example, and consider a Swift library that accesses a database. Its writer has jumped in the protocol-oriented wagon, and provides protocols that grants adopting types fetching and persistence methods:</div><div class=""><br class=""></div><div class="">- RowConvertible: types that can be converted from a database row can be fetched:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Person.fetch(database, "SELECT …")</div><div class=""><br class=""></div><div class="">- TableMapping: types that are linked to a database table. On top of RowConvertible, it grants fetching by primary key:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Person.fetch(database, key: 12)</div><div class=""><br class=""></div><div class="">- DatabasePersistable (inherits from TableMapping): types that can be saved in the database:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Person(name: "Arthur").insert(database)</div><div class=""><br class=""></div><div class="">So far, so good. How does look a user type that uses all those features?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct Person: RowConvertible, TableMapping, DatabasePersistable { … }</div><div class=""><br class=""></div><div class="">That’s quite a long declaration, but it works.</div><div class=""><br class=""></div><div class="">Enter another feature: changes tracking. Changes tracking requires remembering reference data in order to see what’s changed. Protocols don’t (yet) provide stored properties, so the library, today, has to expose a class for this purpose. That class is *abstract* since subclasses *have* to override the method that tells the table name.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>class Record: RowConvertible, TableMapping, DatabasePersistable { … }</div><div class=""><br class=""></div><div class="">How does look a user type that provides the full toolkit (fetching + persistence + changes tracking) ?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>class Person: Record { … }</div><div class=""><br class=""></div><div class="">Sweet! Can you see how the abstract Record class provides:</div><div class=""><br class=""></div><div class="">1. less mental overhead for the library user (a single type provides the full toolkit)</div><div class="">2. Succinct user types declaration (you don’t have to learn about the three core protocols, just inherit from Record)</div><div class="">3. features that protocols can’t provide (here, changes tracking)</div><div class=""><br class=""></div><div class="">In conclusion: protocol-oriented programming is *more complex* than class-based programming. I think that it is important that the Swift ecosystem lets libraries expose simple entry points even though they provide a list of small and focused protocols that can be composed, because protocol composition requires more engagement from library users.</div><div class=""><br class=""></div><div class="">In the example above, the Record class would benefit from being declared abstract, if the language would support such feature. BTW, that Record class exists: <a href="https://github.com/groue/GRDB.swift#database-protocols-and-record" class="">https://github.com/groue/GRDB.swift#database-protocols-and-record</a>.</div><div class=""><br class=""></div><div class="">Gwendal</div><div class=""><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=7XtDdMHRjqIUi4tzSjSp2pWQIyxYdP6woIWn4vwV5geViEPtOAInZBNUkmY5p87HS0-2FRz7VqQ7cU-2B3Qc5OpLtNkWE4fTQxX1bjxxB89VTxDyG0rjWBZmX11ZLiR7Izxn4nAbPU3yEg7ttPeq9xjGdxrNktBWfC5jVZcV6oSkYl6x3GwwXtAJeF74ZTG7S-2BwH2oy3kgg2N0rrLB6ryt3TdBfvd3wlQ31G5SamVX1UkBs-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></div></body></html>