[swift-evolution] JSONEncoder: Key strategies

Mike Kluev mike.kluev at gmail.com
Sat Nov 11 19:52:04 CST 2017


On 11 November 2017 at 21:56, Eagle Offshore <eagleoffshore at me.com> wrote:

> I have to agree, would be better to allow one to provide a mapping
> dictionary or delegate.  Building the encodingKeys into the class itself is
> short sighted and a half measure.
>
> Different types of codings will necessarily desire different key sets and
> even different names for what are logically the same keys.  This absolutely
> should NOT be baked into the class that implements Codable but rather maybe
> a delegate that is presented each key/value and given an opportunity to
> provide a substitute key and value.
>
> Codable is a fairly useless one trick pony in its current incarnation.  It
> doesn't really solve any problem I have with respect to interacting with
> web services.
>
>

in defence of Codable, my experience so far told me:

- it is very useful

- easy to use especially when you can change those structures / keys, e.g.
when you have an influence on the service side as well, or the service side
is designed at the same time - when you start from clean state in other
words.

- even if you need to talk to an already established service - the key's
translation it's doable now (could have been easier though)

- it is very logical to hook the logic of the key translation in the
Codable subclass itself (maybe in a different form to what it is now)
rather than do it externally - the latter is a more "manual" and thus a
more error prone approach where things can be easily screwed.

- the ideal design (not current) would allow to do the translation the way
you want (e.g. via the delegate). so shall be win-win.

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


More information about the swift-evolution mailing list