Just a quick follow up on that last reply… As dumpy of an excuse as that is (doing it because the other 2 big platforms do it) when we’re talking about some tech that is very cross platform, I think it’s worth considering.
Brandon Sneed From: <swift-corelibs-dev-boun...@swift.org> on behalf of "Sneed, Brandon via swift-corelibs-dev" <swift-corelibs-dev@swift.org> Reply-To: "Sneed, Brandon" <brsn...@ebay.com> Date: Wednesday, August 30, 2017 at 3:29 PM To: Tony Parker <anthony.par...@apple.com> Cc: "swift-corelibs-dev@swift.org" <swift-corelibs-dev@swift.org> Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON encode/decode Yeah, I don’t know about the “many types” part. But essentially, if you’re a service developer, you’ll probably have at least 3 clients. Web, Android and iOS. Javascript does this conversion transparently, GSON also does this conversion. iOS ends up being the odd man out in this case. This is entirely me trying to put myself in the service developers shoes… but if I come up with an API contract, that will typically consist of endpoint, overall structure and namin. I can imagine type may fall off my radar given that javascript (the platform I wrote my service in) hides types from me. Using that example at a larger company, the “hey you broke me by changing the type!” scream is followed with “it works fine on web and android”, which in turn causes me to rev the iOS app and wait for people to update. If it failed on all 3, they’d likely fix/rever the service to avoid having *all* clients broken. Brandon Sneed From: <anthony.par...@apple.com> on behalf of Tony Parker <anthony.par...@apple.com> Date: Wednesday, August 30, 2017 at 3:22 PM To: "Sneed, Brandon" <brsn...@ebay.com> Cc: Youming Lin <y...@us.ibm.com>, "swift-corelibs-dev@swift.org" <swift-corelibs-dev@swift.org> Subject: Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON encode/decode On Aug 30, 2017, at 3:12 PM, Sneed, Brandon <brsn...@ebay.com<mailto:brsn...@ebay.com>> wrote: Thanks Tony, Ah. That should work, and covers benefit #2 I mentioned very nicely. Only downside is that as a developer on an app I may not expect that type to change on the server side so I wouldn’t do it by default, and when it does happen, I then need to apply it to each of its siblings because if it can happen to one, it can happen to the others. In this case, the server decides to send a String instead of a numeric value for many kinds of types? I understand that some JSON libraries have options to stringify all numeric values in an attempt to preserve ‘exactness’, although I would argue that this depends on what you do with the numeric value on the other side… - Tony
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
