[swift-evolution] [Draft] open and public protocols

Brent Royal-Gordon brent at architechies.com
Sun Feb 19 17:15:58 CST 2017


> On Feb 18, 2017, at 10:58 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I am unsure if this feature is a good idea. Does someone have a real-world use for this which isn’t just hiding strong implementation coupling behind a protocol?

Strong coupling is sometimes inevitable.

In a previous thread, I brought up an example of a place I would use this feature: Wrapping the SQLite APIs. For instance:

	public protocol SQLiteValue {
		init(statement: SQLiteStatement, columnAt index: Int) throws
		func bind(to statement: SQLiteStatement, at index: Int) throws
	}
	extension Int: SQLiteValue {
		public init(statement: SQLiteStatement, columnAt index: Int) throws {
			self = sqlite3_column_int(statement.stmt, index)
		}
		public func bind(to statement: SQLiteStatement, at index: Int) throws {
			try throwIfNotOK(
				sqlite3_bind_int64(statement.stmt, index, self)
			)
		}
	}
	extension Double: SQLiteValue {…}
	extension Data: SQLiteValue {…}
	extension String: SQLiteValue {…}
	extension Optional: SQLiteValue where Wrapped: SQLiteValue {…}

This is a case of your hated "strong implementation coupling". But the coupling is to a library that ultimately writes data to disk in a portable format. Strong coupling here is inevitable.

What is the purpose of permitting outside conformances to `SQLiteValue`? There is no useful way to conform to `SQLiteValue`; the underlying library supports certain types, and I've implemented support for those types. Allowing outside conformances can only mislead people into fruitlessly trying to conform their types, not realizing that the calls they need simply aren't exposed.

Moreover, exposing these details unnecessarily freezes the design of `SQLiteValue`. If I want to change the design of this parameter handling in a future version, well, too bad, the API is public, I'm stuck. *For an API I don't intend anyone to conform to publicly in the first place.* That kind of sucks, doesn't it?

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list