[swift-evolution] [Proposal] Foundation Swift Archival & Serialization
Itai Ferber
iferber at apple.com
Thu Mar 23 11:34:45 CDT 2017
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>
More information about the swift-evolution
mailing list