 //: customization freedom.
 //:
 //: To end this tour, let's quickly look at two other possible customized
-//: row decoding strategies:
-//:
-//: - Your application needs to decode rows with a context: each decoded value
+//: row decoding strategies.
+//:
+//: ## An Example: Contextualized Records
+//:
+//: Your application needs to decode rows with a context: each decoded value
 //: should be initialized with some extra value that does not come from
 //: the database.
 //:
-//:     In this case, you may define a `ContextFetchableRecord` protocol, and
-//:     derive all other fetching methods from the most fundamental one, which
-//:     fetches a cursor from a prepared statement (as above):
+//: In this case, you may define a `ContextFetchableRecord` protocol, and
+//: derive all other fetching methods from the most fundamental one, which
+//: fetches a cursor from a prepared statement (as we did for the
+//: MyDatabaseDecoder protocol, above):
 
 protocol ContextFetchableRecord {
     associatedtype Context

        }
    }
    
    // Define fetchAll, fetchOne, ...
}

//: - Your application needs a record type that supports untrusted databases,
//: and may fail at decoding database rows (throw an error when a row contains
//: invalid values).
//:
//:     In this case, you may define a `FailableFetchableRecord` protocol, and
//:     derive all other fetching methods from the most fundamental one, which
//:     fetches a cursor from a prepared statement (as above):

protocol FailableFetchableRecord {
    init(row: Row) throws

//: few extensions that guarantee the most efficient use of GRDB, and have the
//: Base class adopt this protocol.
//:
//: ### Keep It Simple, Stupid!
//:
//: But first, let's see how polymorphic decoding can be done as simply as
//: possible. After all, it is useless to design a full-fledged protocol unless
