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

[Brent Royal-Gordon]

> On Mar 17, 2017, at 3:35 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> In all seriousness, I see the design as very slightly weak, in that it makes it easy to forget to pass a context through, but quite acceptable. 
> 
> Easy for who?  I was not requiring Codable types to thread it through at all.  The context was fully managed by the Encoder / Decoder type.  The only place Codable types work with the context is as an argument they receive.  They never pass it when encoding or decoding anything.  The Encoder / Decoder would need to store the context internally and when call is made to encode / decode a ContextAwareCodable it would pass the result of a dynamic cast to ContextAwareCodable.Context as the context.

Oh, I see. Sorry, I missed that when I was looking at your design.

In practice, in my design, you would only need to manually pass a context to `encode(_:forKey:with:)` if the context was of a different type than `self`'s. This would probably happen at module or subsystem boundaries. Imagine, for instance, that your FooKit module (for interacting with the foo.io web service) needs to encode a GeoKit.Location instance, but both FooKit and GeoKit need information from a context to encode themselves properly, and they use different context types. When FooKit encoded a GeoKit.Location, it could construct and pass a GeoKit context.

I believe that in your design, unless the FooKit context was a subtype of the GeoKit context, you wouldn't be able to get GeoKit.Location to do the right thing.

If that weren't the case—if you were encoding a type with a matching context, or with a `Void` context—you could use the two convenience methods, which would handle the context argument for you. So threading contexts would only be necessary in a relatively rare case.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170317/dcc31934/attachment.html>