<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=""><br class=""><div><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>It’s not only about fashion, is it?</div><div><br class=""></div><div>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><br class=""></div><div>- RowConvertible: types that can be converted from a database row can be fetched:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Person.fetch(database, "SELECT …")</div><div><br class=""></div><div>- TableMapping: types that are linked to a database table. On top of RowConvertible, it grants fetching by primary key:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Person.fetch(database, key: 12)</div><div><br class=""></div><div>- DatabasePersistable (inherits from TableMapping): types that can be saved in the database:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Person(name: "Arthur").insert(database)</div><div><br class=""></div><div>So far, so good. How does look a user type that uses all those features?</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>struct Person: RowConvertible, TableMapping, DatabasePersistable { … }</div><div><br class=""></div><div>That’s quite a long declaration, but it works.</div><div><br class=""></div><div>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><br class=""></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>class Record: RowConvertible, TableMapping, DatabasePersistable { … }</div><div><br class=""></div><div>How does look a user type that provides the full toolkit (fetching + persistence + changes tracking) ?</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>class Person: Record { … }</div><div><br class=""></div><div>Sweet! Can you see how the abstract Record class provides:</div><div><br class=""></div><div>1. less mental overhead for the library user (a single type provides the full toolkit)</div><div>2. Succinct user types declaration (you don’t have to learn about the three core protocols, just inherit from Record)</div><div>3. features that protocols can’t provide (here, changes tracking)</div><div><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>Gwendal</div><div><br class=""></div></body></html>