[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