[swift-evolution] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

Morten Bek Ditlevsen bek at termestrup.dk
Fri Oct 20 00:38:47 CDT 2017


Hi Tony,
Sounds really excellent. Looking forward to it.
Please let me know if there's anything regarding proposal or implementation
that I can help with.
/morten

On Thu, Oct 19, 2017 at 5:09 PM Tony Parker <anthony.parker at apple.com>
wrote:

> Hi Morten,
>
> I’ve actually been working on this same idea already and will have
> something to propose soon.
>
> - Tony
>
> On Oct 19, 2017, at 2:03 AM, Morten Bek Ditlevsen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi all,
> At work we have just added Codable support for a whole bunch of model
> objects in our code base.
> Many places we have added CodingKeys enumeration in order to convert the
> camel cased property names to snake case for our JSON keys.
> As an experiment I have tried adding a KeyCodingStrategy option to a copy
> of the JSONEncoder and JSONDecoder implementations.
> This is currently an enumeration with the following values
> .original
> .snakeCase
> .custom((String) -> String)
>
> I just extended CodingKey as follows:
> extension CodingKey {
>     func stringValue(with encodingStrategy:
> StructuralEncoder.KeyEncodingStrategy) -> String {
>         switch encodingStrategy {
>         case .original:
>             return stringValue
>         case .snakeCase:
>             let pattern = "([a-z0-9])([A-Z])"
>             let regex = try! NSRegularExpression(pattern: pattern,
> options: [])
>             let range = NSRange(location: 0, length:
> stringValue.characters.count)
>             return regex.stringByReplacingMatches(in: stringValue,
> options: [], range: range, withTemplate: "$1_$2").lowercased()
>         case .custom(let t):
>             return t(stringValue)
>         }
>     }
> }
>
> and then I replaced all references to key.stringValue with
> key.stringValue(with: self.encoder.options.keyCodingStrategy)
>
> This seems to work very nicely.
>
> So my question is: Do anyone else see the benefit of such an addition to
> the JSONEncoder and JSONDecoder?
>
> The downside as I see it, is that the current CodingKeys are guaranteed to
> be unique by the compiler, and it would be possible to create collisions by
> using key name transforms.
> Is this downside bigger than the gains?
>
> One advantage is that one could argue that one CodingKey strategy may not
> fit all serialization mechanisms. For instance one might wish to have upper
> camel cased keys in Plists (just an example) and snake case in JSON. This
> method could easily support this, while the current CodingKeys strategy
> cannot...
>
> Looking forward to hearing feedback.
>
> Sincerely,
> /morten
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171020/30030c60/attachment.html>


More information about the swift-evolution mailing list