Return UserDefaults dictionaryRepresentation double values as doubles#67
Conversation
|
Thanks very much for this! But I had been hoping for a solution more in line with the description at #54, where each stored property has a "sidecar" property with the expected type. That would allow us to disambiguate not only between Long/Double and Int/Float values, but also Date/Data/URL/String without doing any additional parsing, as well as opening the door to possibly support array defaults. This would be a bit more of an overhaul than a quick fix, so I can take it on in the next couple days if you like. But if you want to tackle it, please go ahead. |
3dc34e3 to
672d2f9
Compare
marcprux
left a comment
There was a problem hiding this comment.
This is looking great! In addition to the couple of nits, could you also ensure that when a default is removed or nil'd that it also removes the __unrepresentable__ sidecar value if it exists?
672d2f9 to
aa512c7
Compare
|
Looks great, thanks! |
Fixes #54
This implementation adds a "sidecar" property
__unrepresentableTypewhen you set a value that's unrepresentable inSharedPreferences. (We do not set a sidecar property when the type is representable, to avoid waste.)Note that this implementation no longer sets floats as
IntviaFloat.toRawBits(), becauseSharedPreferencessupportsFloatvalues natively; the tests verify that we can store arbitrary precision floats. (The tests also verify that floats that were saved asIntbits can be restored, guaranteeing backwards compatibility.)We're also now no longer adding prefix strings for the types stored as strings:
Data,Date, andURL. But, again, the backwards compatibility tests ensure that values stored before this change can still be deserialized as expected.Skip Pull Request Checklist:
swift test