-
-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the API for choosing the type of serialization #162
Comments
For this case, we could consider enhancing the RawRepresentableCodableBridge. |
A value could potentially be loadable by both. This creates ambiguity and potential data-loss.
Yes, that's a different case and unrelated to this issue. |
How about change the public func deserialize(_ object: Serializable?) -> Value? {
// Check whether it can deserialize with `CodableBridge`
if
let jsonString = object as? String,
let value = try? Value(jsonString: jsonString)
{
return value
}
guard let object = object as Value.RawValue else {
return nil
}
return Value(rawValue: object)
} It will accept serialization values from both |
To clarify my point. The potential problem is that the raw serialized value could be a string from a RawRepresentable serialization, but when deserialized using Codable it turns into a different value. I don't think we should guess the user's intent. It's better to be explicit about what you want. In addition, trying to use Codable each time |
Get your point.
private enum FixtureCodableEnum: String, Hashable, Codable, Defaults.Serializable {
case tenMinutes = "10 Minutes"
case halfHour = "30 Minutes"
case oneHour = "1 Hour"
}
extension FixtureCodableEnum {
typealias Bridge = Defaults.RawRepresentableCodableBridge<Self>;
}
// in `Defaults.Key.init`
if defaultValue is Codable, defaultValue is any RawRepresentable {
runtimeWarn(false, "Please consider using `Defaults.Serializable.RawRepresentable` for serialization/deserialization stability")
} |
Why not? private enum FixtureCodableEnum: String, Hashable, Codable, Defaults.Serializable.RawRepresentable {
case tenMinutes = "10 Minutes"
case halfHour = "30 Minutes"
case oneHour = "1 Hour"
} |
Yeah, of course we can do this, but we might need to warn user when they are using ambiguous bridge to do the serialization and deserialization. With this user will need to specify the bridge they want to use. |
I think |
Got it! Many thanks! |
Yes. And |
Current:
I think this may be better:
This is shorter, but more importantly, it makes the choice explicit. Users should prefer this over
Defaults.Serializable
.Defaults.Serializable
has a big flaw. For example, you have astruct X: Codable, Defaults.Serializable
. You save data with it, but later on, you add aRawRepresentable
conformance. The previous persisted version of the struct can no longer be loaded as it's saved using theCodable
bridge, but now tries to load using theRawRepresentable
bridge.// @hank121314 Thoughts? Any better way to prevent this problem?
The text was updated successfully, but these errors were encountered: