> What is your evaluation of the proposal?
-1. Like I said in my review of 167, this sort of core API is far too important
for the implementation to be so flawed.
* This proposal is extensive. An implementation playground would’ve been nice.
Containers seem fairly odd, so it would’ve been nice to see how they feel in
use.
* Like 167, this proposal feels very Objective-C like. While we want
interoperability with NSCoder and NSKeyedArchiver, this should be a native
Swift solution first and a bridge second. Also, some bits of the API aren’t
Swifty; any API which uses Type.self just doesn’t feel right. Please, use the
generics.
someString = try container.decode(forKey: .someString) can infer the type from
the assignee, no?
* This sort of API works well when the responses are logically formed, but this
also forms the basis of the APIs we’ll be using to interact with JSON, which
can be anything but logically formed. For instance:
struct Veritas {
let truth: Bool
}
Simple, right?
But say it’s JSON representation is this:
{ “some_Bad_key” : “Yes” }
How would this proposal let me transform a Yes string into the proper boolean
value? There doesn’t seem to be a solution provided, just the brute force
method of trying to decode as a string first and then transforming. Plus, if I
have a single value that I need to do something custom to, I need implement
init(from decoder:) for my entire type, so it becomes very painful very
quickly. I foresee a new collection of open source libraries to remedy this
shortcoming, and they really shouldn’t have to.
Also, what if I wanted to be able to decode this type from both the terrible
JSON and a nice on disk format? Some way to provide multiple conforming
initializers would be nice.
Suffice to say my biggest concern here is that this API is designed for the
ideal and not the messy reality of JSON APIs created by the lowest bidder.
Since this proposal is supposed to cover both, it needs to offer support for
the worst case scenarios more easily.
* The errors generated just aren’t good. I covered this in more detail in my
review of 167, but suffice it to say they’re too limited by the desire to
bridge them to NSErrors and don’t capture any useful details about what caused
them in the first place. Also, they shouldn’t live in Foundation, as this is a
feature the standard library will implement.
> Is the problem being addressed significant enough to warrant a change to
> Swift?
Yes, this is a problem worth solving, I just don’t think this proposal is good
enough.
> Does this proposal fit well with the feel and direction of Swift?
No. Passing types around isn’t Swifty at all. This fits right in in Objective-C
though.
> If you have used other languages or libraries with a similar feature, how do
> you feel that this proposal compares to those?
I’ve been an Argo user for 2 years, so I’m used to a certain terseness and
flexibility in my decoders. This proposal brings neither. Argo also has
superior errors which capture the keys and types that caused an issue. I
guarantee there will be at least one open source library which provides
operators that wrap this proposal’s API so that you can properly transform
decoded values without multiple lines of code.
> How much effort did you put into your review? A glance, a quick reading, or
> an in-depth study?
Multiple read throughs, about an hour of analysis.
Jon Shier_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
