Sent from my iPad
> On Mar 16, 2017, at 5:59 PM, Itai Ferber <[email protected]> wrote: > > On 16 Mar 2017, at 15:45, Matthew Johnson wrote: > > > On Mar 16, 2017, at 5:37 PM, Itai Ferber <[email protected]> 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. > > 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. > Fair enough. This makes sense given the rest of the details. I'm glad to hear you're copying them to the internal types when starting encoding / decoding! :) > 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
