[swift-evolution] [Proposal] Foundation Swift Archival & Serialization
Matthew Johnson
matthew at anandabits.com
Tue Mar 21 11:16:04 CDT 2017
> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>
> On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
> Here's what I mean: Suppose I have a BlogPost model, and I can both fetch and post BlogPosts to a cross-platform web service, and store them locally. But when I fetch and post remotely, I ned to conform to the web service's formats; when I store an instance locally, I have a freer hand in designing my storage, and perhaps need to store some extra metadata. How do you imagine handling that sort of situation? Is the answer simply that I should use two different types?
>
> This is a valid concern, and one that should likely be addressed.
>
> Perhaps the solution is to offer a userInfo : [UserInfoKey : Any] (UserInfoKey being a String-RawRepresentable struct or similar) on Encoder and Decoder set at the top-level to allow passing this type of contextual information from the top level down.
>
>
> I assumed that in those situations, one would create a wrapper struct,
>
> struct WebBlogModel {
> let wrapped: BlogModel
> }
>
> probably for the encoding impl that requires more custom work. The implementation of Codable for this struct would then serialize (deserialize) from (to) its wrapped value's properties directly.
>
> Types already provide a means for performing context sensitive implementation selection, I don't think it's necessary to provide another way to do that in Swift. Of course I could very well be wrong :)
Wrappers like this give you a way to implement different encoding strategies but they don’t help you identify which strategy to use for a given encoding. You need a user-defined context to do that. Brent has proposed a couple of different designs to facilitate this which are nicer than a user info dictionary.
>
> -Colin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/71fabf22/attachment.html>
More information about the swift-evolution
mailing list