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

[Itai Ferber]

Hi Oliver,

Thanks for your comments! We thought about this and we agree overall — 
we will incorporate this suggestion along with others in the next batch 
update as long as nothing prohibitive comes up.

— Itai

On 23 Mar 2017, at 7:49, Oliver Jones 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) and 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


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