On 16 Mar 2017, at 15:45, Matthew Johnson wrote:
> On Mar 16, 2017, at 5:37 PM, Itai Ferber <ifer...@apple.com> wrote:
On 16 Mar 2017, at 14:48, Matthew Johnson wrote:
Thank you again for bringing these great proposals forward!
Thanks for reviewing it, and for your comments!
I only have a couple of questions about this proposal.
I noticed that the types in this proposal don’t conform to Encoder
and Decoder. Is the plan to have them to provide private conforming
types to Codable types they are asked to encode or decode?
Yes. This is because the top-level interface for encoding and
decoding in JSON and plist is different from the intermediate
interface that Encoder and Decoder offer. As such, the top-level
types don’t conform to Encoder and Decoder, but vend out internal
types which do.
This makes sense. I was initially concerned about the meaning of
mutating these values during encoding or decoding but it looks like
that isn’t possible without some really nefarious code that passes a
reference to the top-level encoder / decoder to an object that is
getting encoded / decoded. What will you do if somebody actually does
this?
The options are copied immutably into the internal types and the
originals are not consulted during the process of encoding or decoding
— we want to prevent exactly this.
FWIW, you can see the current implementation of this on [the
implementation PR](https://github.com/apple/swift/pull/8124).
Why are the strategy and format properties readwrite instead of
configured at initialization time? Is the intent that the encoder /
decoder can be re-used with a different configuration in a subsequent
call to encode or decode?
Yes. It’s also a mouthful to have them all as params in the
constructor, especially if we add more options in the future.
Taking them in an initializer would not need to be wordy - they could
all specify default arguments.
Sure, but if you want to specify a lot of them…
But, this is more of a stylistic argument. Six of one, half-dozen of
another. The more useful thing is supporting mutation after
initialization, which is a reasonable thing to want to do.
Finally, I agree with Brent’s comments regarding errors. I would
prefer to see Foundation move away from NSError in favor of
domain-specific error types. That said, the comment that this is a
broader discussion for Foundation and not something to change in this
proposal is reasonable. I hope Foundation will consider changing this
in the future.
Thanks for your understanding — we will keep these concerns in
mind.
Matthew
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution