[swift-evolution] [Proposal] Foundation Swift Archival & Serialization
brent at architechies.com
Fri Mar 17 18:15:43 CDT 2017
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution