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

[Jonathan Hull]

Let me vote +1 for splitting it.  The added conceptual complexity should be minimal, since it is progressively disclosed.  You only need to know about codeable, unless you run into the issue where you only want one, at which point stack overflow, etc… will point you to Encodable/Decodable and you will be glad they exist.


> On Mar 23, 2017, at 11:44 AM, Tony Parker via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Oliver,
> 
>> On Mar 23, 2017, at 7:55 AM, Oliver Jones via swift-evolution <swift-evolution at swift.org <mailto: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
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170323/9c0428ca/attachment.html>