On 11 November 2017 at 21:56, Eagle Offshore <eagleoffsh...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
