<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yes, in general, I think Codable is a poor solution for json decoding just like I never used NSCoding to convert JSON to and from objects. It feels clumsy.<div class=""><br class=""></div><div class="">I found it a much better solution to add a category to NSObject that had</div><div class=""><br class=""></div><div class="">-(NSData*)toJSONRepresentationWithMappings:(NSDictionary*)d</div><div class="">+()fromJSONRepresentation:(NSData*) mappings:(NSDictionary*)d</div><div class=""><br class=""></div><div class="">where mappings might be { @"firstName": @"first_name", etc.... }</div><div class=""><br class=""></div><div class="">and was simple to write a general solution using introspection and KVC.</div><div class=""><br class=""></div><div class="">Codable is a limited one trick pony that would be trivial to write as a trait or extension if Swift provided the more profound thing - introspection and reflection. A whole world of opportunities would open up with that and we could stop wasting time on Codable and KeyPath - neither of which is that useful when working with string data from the wild.</div><div class=""><br class=""></div><div class="">Please stop messing about with these lil special cases and provide a general introspection and reflection capability. Until Swift has that, I might as well use C++.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 19, 2017, at 2:03 AM, Morten Bek Ditlevsen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><span style="font-size:13px" class="">Hi all,</span><div style="font-size:13px" class="">At work we have just added Codable support for a whole bunch of model objects in our code base.</div><div style="font-size:13px" class="">Many places we have added CodingKeys enumeration in order to convert the camel cased property names to snake case for our JSON keys.</div><div style="font-size:13px" class="">As an experiment I have tried adding a KeyCodingStrategy option to a copy of the JSONEncoder and JSONDecoder implementations.</div><div style="font-size:13px" class="">This is currently an enumeration with the following values</div><div style="font-size:13px" class="">.original</div><div style="font-size:13px" class="">.snakeCase</div><div style="font-size:13px" class="">.custom((String) -> String)</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">I just extended CodingKey as follows:</div><div style="font-size:13px" class=""><div class="">extension CodingKey {</div><div class=""> func stringValue(with encodingStrategy: StructuralEncoder.KeyEncodingStrategy) -> String {</div><div class=""> switch encodingStrategy {</div><div class=""> case .original:</div><div class=""> return stringValue</div><div class=""> case .snakeCase:</div><div class=""> let pattern = "([a-z0-9])([A-Z])"</div><div class=""> let regex = try! NSRegularExpression(pattern: pattern, options: [])</div><div class=""> let range = NSRange(location: 0, length: stringValue.characters.count)</div><div class=""> return regex.stringByReplacingMatches(in: stringValue, options: [], range: range, withTemplate: "$1_$2").lowercased()</div><div class=""> case .custom(let t):</div><div class=""> return t(stringValue)</div><div class=""> }</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">and then I replaced all references to key.stringValue with key.stringValue(with: self.encoder.options.keyCodingStrategy)</div><div class=""><br class=""></div><div class="">This seems to work very nicely.</div><div class=""><br class=""></div><div class="">So my question is: Do anyone else see the benefit of such an addition to the JSONEncoder and JSONDecoder?</div><div class=""><br class=""></div><div class="">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.</div><div class="">Is this downside bigger than the gains?</div></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">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...</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">Looking forward to hearing feedback.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">Sincerely,</div><div style="font-size:13px" class="">/morten</div><div class=""><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>