[swift-evolution] [Review] SE-0166: Swift Archival & Serialization
anviking at me.com
Thu Apr 13 09:48:26 CDT 2017
This might be too late, but anyway:
> What is your evaluation of the proposal?
Unsure. For archival purposes/NSCoding replacement this seems great. As the best way to do decode JSON from external APIs I find it at least to be very unconvincing. But then, I’m not sure if this is a goal of the proposal.
> Is the problem being addressed significant enough to warrant a change to Swift?
I don’t know.
> Does this proposal fit well with the feel and direction of Swift?
To me the proposed implementation doesn’t seem particularly elegant or Swifty.
> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
(Assuming decoding JSON from external APIs is a goal)
From creating and maintaining the Decodable <https://github.com/Anviking/Decodable> library I learned:
- There are lots of weird APIs out there, that ultimately should be simple to support (e.g how optional values are described, bools as strings, 1-length arrays represented without the wrapping array, etc, etc). This proposal doesn’t talk about these kinds of problems (I don’t even see an optional property in an example), and I haven’t been able to get a sense of whether they are solvable or not with the proposed implementation, which I do not fully understand.
- Good error messages (with like backtraces) are important when writing lots of of decoding code by hand. I see no mentions of error messages in these proposals. Swift-Error breakpoints, could be a solution, but from my experience it’s not really feasible.
> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Several quick readings and quite a bit of thinking. I am really confused by these proposals though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution