[swift-evolution] [Proposal draff] abstract classes and methods

[Austin Zheng]

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.

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.

Austin

> On Jan 7, 2016, at 11:22 PM, Gwendal Roué via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Le 7 janv. 2016 à 20:41, Charles Constant via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> > I am not sure that the language should discourage a feature it supports and impose friction on it because it could be abused.
>> 
>> 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.
> 
> It’s not only about fashion, is it?
> 
> 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:
> 
> - RowConvertible: types that can be converted from a database row can be fetched:
> 
> 	Person.fetch(database, "SELECT …")
> 
> - TableMapping: types that are linked to a database table. On top of RowConvertible, it grants fetching by primary key:
> 
> 	Person.fetch(database, key: 12)
> 
> - DatabasePersistable (inherits from TableMapping): types that can be saved in the database:
> 
> 	Person(name: "Arthur").insert(database)
> 
> So far, so good. How does look a user type that uses all those features?
> 
> 	struct Person: RowConvertible, TableMapping, DatabasePersistable { … }
> 
> That’s quite a long declaration, but it works.
> 
> 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.
> 
> 	class Record: RowConvertible, TableMapping, DatabasePersistable { … }
> 
> How does look a user type that provides the full toolkit (fetching + persistence + changes tracking) ?
> 
> 	class Person: Record { … }
> 
> Sweet! Can you see how the abstract Record class provides:
> 
> 1. less mental overhead for the library user (a single type provides the full toolkit)
> 2. Succinct user types declaration (you don’t have to learn about the three core protocols, just inherit from Record)
> 3. features that protocols can’t provide (here, changes tracking)
> 
> 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.
> 
> 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: https://github.com/groue/GRDB.swift#database-protocols-and-record <https://github.com/groue/GRDB.swift#database-protocols-and-record>.
> 
> Gwendal
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/73a9a61a/attachment.html>