[swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Tony Parker]

Hi Oliver,

> On Mar 23, 2017, at 7:55 AM, Oliver Jones via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Like everyone I’m excited by this new proposal.  But…
> 
> > protocol Codable: Adopted by types to opt into archival. Conformance may be automatically derived in cases where all properties are also Codable.
> 
> … can I make one suggestion.  Please do not repeat the mistakes of NSCoding in combining the encoding and decoding into a single protocol.  Just as there are Encoder and Decoder classes their should be Encodable and Decodable protocols (maybe have an aggregate Codable protocol for convenience but do not force it).
> 
> My reasoning:
> 
> Sometimes you only want to decode or encode and object and not vice versa.  This is often the case with Web APIs and JSON serialisation.  
> 
> Eg:
> 
> Often an app only consumes (decodes) JSON encoded objects and never writes them out (a read only app for example). So the encode(to:) methods are completely redundant and someone adopting Codable should not be forced to write them.  
> 
> If only I had a dollar for all the times I’ve seen this sort of code in projects:
> 
> class MyClass : NSCoding {
> init?(coder: NSCoder) {
>   // ... some decoding code
> }
> 
> func encode(with aCoder: NSCoder) {
>    preconditionFailure(“Not implemented”)
> }
> }
> 
> 
> Another example: 
> 
> Web APIs often take data in a different structure as input (i.e. “Request” objects) than they output.  These request objects are only ever encoded and never decoded by an application so implementing init(from:) is completely redundant.
> 
> Personally I think the approach taken by libraries like Wrap (https://github.com/johnsundell/wrap <https://github.com/johnsundell/wrap>) and Unbox (https://github.com/JohnSundell/Unbox <https://github.com/JohnSundell/Unbox>) is a much better design.  Encoding and decoding should not be the same protocol.
> 
> Yes I understand that Codable could provide no-op (or preconditionFailure) protocol extension based default implementations of init(from:) and encode(to:) (or try to magic up implementations based on the Codable nature of public properties as suggested in the proposal) but to me that seems like a hack that is papering over bad design.  I think this joint Codable design probably fails the Liskov substitution principle too.
> 
> So I again implore you to consider splitting Codable into two protocols, one for encoding and another for decoding.
> 
> Sorry if I’m repeating what other people have already said.  I’ve not read every response to this proposal on the list.
> 
> Regards

Thanks for your feedback. We are indeed considering splitting this up into 3 protocols instead of 1 (“Encodable", “Decodable", "Codable : Encodable, Decodable”).

The main counterpoint is the additional complexity inherent in this approach. We are considering if the tradeoff is worth it.

- Tony


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170323/b3e2caca/attachment.html>