> On Mar 21, 2017, at 11:24 AM, Colin Barrett <[email protected]> > wrote: > > 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?
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. 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. 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. > > -Colin > > > On Tue, Mar 21, 2017 at 12:16 PM Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: >> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
