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

Gwendal Roué gwendal.roue at gmail.com
Fri Jan 8 01:22:43 CST 2016

> Le 7 janv. 2016 à 20:41, Charles Constant via swift-evolution <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>.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160108/59917f26/attachment.html>

More information about the swift-evolution mailing list