You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to add some detail into why I think this is important:
In the case of our REST API we've made a backend framework which handle automatic conversion of JSON response into Swift objects.
Previously we used reflection, and setValue so we had to inherited of NSObject.
With Codable and JSONDecoder we wants to do it in pure Swift.
Our REST API is pretty standard, our objects share different base properties across our endpoint, so we want to have a base class/struct which implement Codable and some standard properties (like an object id). And then have subclass if this for any object which is usable with our API.
I hope it make sense, and I get why it may be not the best be doable. But I think it would be good to think about this use case.
As mentioned in person, there are a few issues here. The primary concern is SR-4772 — Store inherits its parent class's Codable conformance, so it only decodes the properties its parent looks for.
However, even when that is fixed, this type of behavior is not given by default. The default behavior is to do the safe thing: encapsulate parent data using a superEncoder and superDecoder. There is simply no way to know what type of container the parent class will ask for (e.g. Store is allowed to request a keyed encoder/decoder, but BaseStore can ask for an unkeyed encoder/decoder — those can't be shared!), so it's not safe for the compiler to do anything but use those encapsulating encoders.
If you control the parent class and know for a fact that it's safe to pass your own encoder or decoder to them directly, you can do that in a custom encode(to🙂 and init(from🙂:
publicfuncencode(toencoder: Encoder) throws {
// Ask for a container and encode into it.super.encode(to: encoder)
}
Environment
Xcode 9 / Swift 4 / Experimental build system
Additional Detail from JIRA
md5: 37774e4e19ebbc164774b2d906332e01
duplicates:
Issue Description:
In this code, the groceries properties is not deserialised from JSON. The name property is, but not the groceries one.
If you flatify the Store/BaseStore class, it actually works. Is it a bug or a limitation of Encodable?
So this code works:
The text was updated successfully, but these errors were encountered: