[swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Colin Barrett colin at springsandstruts.com
Tue Mar 21 11:24:36 CDT 2017


I'm not sure I follow. What do you mean "which strategy to use for a given
encoding"? IMO there should be at most one implementation of Coding /
Decoding for a particular type. So the way you'd say "I want to decode a
JSON response that implements my blog model" would be, reusing the
definition from above

let wblog = try JSONDecoder().decode(WebBlogModel.self, from: payload)
let blog = wblog.wrapped

What am I missing?

-Colin


On Tue, Mar 21, 2017 at 12:16 PM Matthew Johnson <matthew at anandabits.com>
wrote:

> 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> 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/46be7a98/attachment.html>


More information about the swift-evolution mailing list