> On Mar 17, 2017, at 3:35 PM, Matthew Johnson <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
