I have a throwing style data marshaling layer that uses throwing and return
type inference to make the code clean and validation automatic with the
optional ability to return default values if error or missing value, etc.
This is for validating data coming from external sources into our app.
Having generic return type and throwing subscripts would help make this
code better for clients IMHO.
class Data {
let number: Int
let name: String
}
....
data.number = try helper.value(forKey: "baz")
data.name = try helper.value(forKey: "foo", otherwise: "bar")
....
.... or ideally something like ....
....
data.number = try helper["baz"]
data.name = try helper["foo", otherwise: "bar"]
....
-Shawn
On Sat, Jan 14, 2017 at 9:45 AM Anton Zhilin via swift-evolution <
[email protected]> wrote:
I’m not sure, but I think that in this case the specific type of these
values is determined at runtime.
Then a safe approach would be separate string: String?, bool: Bool?, int:
Int? computed properties, as it’s done in JSON parsers.
if let bookCount = row.value(named: "bookCount").int {
...
}
if let bookCount = row["bookCount"].int {
...
}
let bookCount = row.int("bookCount")! // crash if database is corrupt
Additionally, this is an overall bad example of generics. Fields of
database tables can only map to a limited set of static types in Swift,
which are supported by database adapter.
2017-01-14 16:50 GMT+03:00 Gwendal Roué via swift-evolution <
[email protected]>:
This is a consequence of your vision of subscript. If interesting, it is
also limiting for no real purpose.
As the developer of a Swift database library, I'd like to offer a better
API than the following:
// Current state of affairs
let name: String = row.value(named: "name")
let bookCount: Int = row.value(named: "bookCount")
let hasBooks: Bool = row.value(named: "bookCount")
Instead, I wish I could offer GRDB.swift would let its users write:
// With improved subscripts
let name: String = row["name"]
let bookCount: Int = row["bookCount"]
let hasBooks: Bool = row["bookCount"]
And this requires genericity on return type.
Gwendal
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
