<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 21, 2017, at 11:24 AM, Colin Barrett <<a href="mailto:colin@springsandstruts.com" class="">colin@springsandstruts.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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<div class=""><br class=""></div><div class="">let wblog = try JSONDecoder().decode(WebBlogModel.self, from: payload)</div><div class="">let blog = wblog.wrapped</div><div class=""><br class=""></div><div class="">What am I missing?</div></div></div></blockquote><div><br class=""></div><div>When I have encountered a need for things like this I usually don’t need to encode a whole tree differently based on context. I only need to encode one or two types differently based on context. IMO it would be insane to require wrapper types all the way down the tree that’s getting encoded just so that one or two types can encode themselves using a format specified by a server. I suppose you could make it work but it’s crazy and unnecessary complexity if you ask me.</div><div><br class=""></div><div>Brent’s example was using different formats for local archiving and for cloud persistence. This also seems reasonable. Again wrappers would work but would also be a lot of boilerplate for no obvious win.</div><div><br class=""></div><div>Encoder and Decoder as proposed already include a `codingKeyContext`. We’re just asking for an additional user-defined context which gives information about the purpose of the encoding.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">-Colin</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Mar 21, 2017 at 12:16 PM Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_6746618243437322997Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u class="gmail_msg"></u>
<div class="gmail_msg"><div style="font-family:sans-serif" class="gmail_msg"><div style="white-space:normal" class="gmail_msg"><blockquote style="border-left:2px solid #777;color:#777;margin:0 0 5px;padding-left:5px" class="gmail_msg"><p dir="auto" class="gmail_msg"><br class="gmail_msg">
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?</p>
</blockquote></div>
</div></div><div class="gmail_msg"><div style="font-family:sans-serif" class="gmail_msg"><div style="white-space:normal" class="gmail_msg"><p dir="auto" class="gmail_msg">This is a valid concern, and one that should likely be addressed.</p><p dir="auto" class="gmail_msg">Perhaps the solution is to offer a <code style="background-color:#f7f7f7;border-radius:3px;margin:0;padding:0 0.4em" bgcolor="#F7F7F7" class="gmail_msg">userInfo : [UserInfoKey : Any]</code> (<code style="background-color:#f7f7f7;border-radius:3px;margin:0;padding:0 0.4em" bgcolor="#F7F7F7" class="gmail_msg">UserInfoKey</code> being a <code style="background-color:#f7f7f7;border-radius:3px;margin:0;padding:0 0.4em" bgcolor="#F7F7F7" class="gmail_msg">String</code>-<code style="background-color:#f7f7f7;border-radius:3px;margin:0;padding:0 0.4em" bgcolor="#F7F7F7" class="gmail_msg">RawRepresentable</code> struct or similar) on <code style="background-color:#f7f7f7;border-radius:3px;margin:0;padding:0 0.4em" bgcolor="#F7F7F7" class="gmail_msg">Encoder</code> and <code style="background-color:#f7f7f7;border-radius:3px;margin:0;padding:0 0.4em" bgcolor="#F7F7F7" class="gmail_msg">Decoder</code> set at the top-level to allow passing this type of contextual information from the top level down.</p></div></div></div></blockquote><div class="gmail_msg"> </div><div class="gmail_msg">I assumed that in those situations, one would create a wrapper struct,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">struct WebBlogModel {</div><div class="gmail_msg"> let wrapped: BlogModel</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 :)</div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Wrappers like this give you a way to <i class="gmail_msg">implement</i> 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.</div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-Colin</div></div></div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">
_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>