<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">Hi Oliver,</p>
<p dir="auto">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.</p>
<p dir="auto">— Itai</p>
<p dir="auto">On 23 Mar 2017, at 7:49, Oliver Jones wrote:</p>
</div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="2FCFFDCA-DB67-47D2-9F98-89AB144F8866"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Like everyone I’m excited by this new proposal. &nbsp;But…</div><div class=""><br class=""></div><div class="">&gt; protocol Codable: Adopted by types to opt into archival. Conformance may be automatically derived in cases where all properties are also Codable.<br class=""><div class=""><br class=""></div><div class="">… can I make one suggestion. &nbsp;Please do not repeat the mistakes of NSCoding in combining the encoding and decoding into a single protocol. &nbsp;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).</div></div><div class=""><br class=""></div><div class="">My reasoning:</div><div class=""><br class=""></div><div class="">Sometimes you only want to decode <b class="">or</b> encode and object and not vice versa. &nbsp;This is often the case with Web APIs and JSON serialisation. &nbsp;</div><div class=""><br class=""></div><div class="">Eg:</div><div class=""><br class=""></div><div class="">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. &nbsp;</div><div class=""><br class=""></div><div class="">If only I had a dollar for all the times I’ve seen this sort of code in projects:</div><div class=""><br class=""></div><div class="">class MyClass : NSCoding {</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">init?(coder: NSCoder) {</div><div class="">&nbsp; // ... some decoding code</div><div class="">}</div><div class=""><br class=""></div><div class="">func&nbsp;encode(with&nbsp;aCoder:&nbsp;NSCoder) {</div><div class="">&nbsp; &nbsp;preconditionFailure(“Not implemented”)</div><div class="">}</div></blockquote><div class="">}</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Another example:&nbsp;</div><div class=""><br class=""></div><div class="">Web APIs often take data in a different structure as input (i.e. “Request” objects) than they output. &nbsp;These request objects are only ever encoded and never decoded by an application so implementing init(from:) is completely redundant.</div><div class=""><br class=""></div><div class="">Personally I think the approach taken by libraries like Wrap (<a href="https://github.com/johnsundell/wrap" class="">https://github.com/johnsundell/wrap</a>) and Unbox (<a href="https://github.com/JohnSundell/Unbox" class="">https://github.com/JohnSundell/Unbox</a>) is a much better design. &nbsp;Encoding and decoding should not be the same protocol.</div><div class=""><br class=""></div><div class="">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. &nbsp;I think this joint Codable design probably fails the Liskov substitution principle too.</div><div class=""><br class=""></div><div class="">So I again implore you to consider splitting Codable into two protocols, one for encoding and another for decoding.</div><div class=""><br class=""></div><div class="">Sorry if I’m repeating what other people have already said. &nbsp;I’ve not read every response to this proposal on the list.</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
</blockquote></div>
</div>
</body>
</html>