> On Mar 19, 2017, at 12:21 PM, Tony Parker <[email protected]> wrote:
>>
>> On Mar 19, 2017, at 12:14 PM, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On Mar 19, 2017, at 10:47 AM, Tony Parker <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> Hi Matthew, Brent,
>>>
>>> I see why you are asking for this Context parameter, but putting it into
>>> the basic Codable protocol introduces too much conceptual overhead. There
>>> are too many benefits to keeping adoption to just one protocol, including
>>> discoverability, ease of use, reducing the need for overloads on protocols
>>> elsewhere, and more. Supporting this one use case does not outweigh those
>>> benefits, especially considering I expect that most library code would not
>>> use it (as you say: it would be weird to pass this context between modules).
>>>
>>> Can you figure out a way to get the context info passed through the
>>> encoder/decoder instead? It would make more sense as something optionally
>>> retrieved from the encoder/decoder that was set at the top level.
>>
>> Hi Tony. I can see the argument that the this is a feature that should be
>> relatively rarely used and thus should have as simple a design as possible.
>>
>> If you feel like the impact of threading a typed context on the API surface
>> area is too heavy you could just add a `var context: Any? { get }`
>> requirement to Encoder and Decoder. The expectation is that encoders and
>> decoders would accept a context in the top level call and make it available
>> to all Codable types. This would solve the problem with minimal API impact
>> at the cost of the ability to statically verify that all types receive the
>> context they need to encode / decode correctly.
>>
>> I much prefer the static safety but having a solution is better than not
>> having one. :)
>
> The Any context property is reasonable, but it would be nice to find
> something in the middle. =)
>
> One other possibility is that we define a user info dictionary instead, with
> a custom key type that can be extended (much like our string enumerations).
> In general I haven’t been a fan of the user info pattern in Swift because of
> the necessity to cast, but as you say it’s better than nothing. e.g. userInfo
> : [CodingUserInfoKey: Any].
I hate casting out of Any, and I strongly believe we should support multiple
contexts, so personally, I'd prefer something typed:
protocol Encoder {
// Retrieve the context instance of the indicated type.
func context<Context>(ofType type: Context.Type) -> Context?
// This context is visible for `encode(_:)` calls from this
encoder's containers all the way down, recursively.
func addContext<Context>(_ context: Context, ofType type:
Context.Type)
}
// Likewise on Decoder
// Encoder and decoder classes should accept contexts in their
top-level API:
open class JSONEncoder {
open func encode<Value : Codable>(_ value: Value, withContexts
contexts: [Any] = []) throws -> Data
}
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
