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: on behalf of "Sneed, Brandon via
swift-corelibs-
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
Hi Youming,
No worries. Some of the verbage overlaps enough that it makes the conversation
a little difficult to follow.
The jist is basically that if I type my struct with an Int inside, the JSON
payload contains a string, I want an Int back if at all possible. If my struct
has a string, th
> On Aug 30, 2017, at 3:12 PM, Sneed, Brandon 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 whe
Brandon
Sorry, I didn't realize you want it on the String type since you used other
string ivars in your example as well.
I'm not sure that forcing all numbers to be valid decoded strings is a good
idea, because this behavior gets applied to other string ivars that you may
not want to be compatib
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 bec
I haven’t tried this myself yet, but you could imagine creating a type which
represents an ABV and decodes using a single value container. Then, your custom
behavior goes into the Codable implementation of this ABV type.
Struct Beer then looks like:
struct Beer: Codable {
let name: String
Thanks Youming,
That’s not quite what I meant. I may have misinterpreted what Tony was saying
though.
I wanted to do conversion on String, not the containing type. The problem of
doing it on the containing type is that as soon as you need one field to be
custom, you’re roped into handling al
Brandon
I cooked up a simple example and it works as expected.
ylin@youming-mbpr:~/Swift/Configuration$ swift
Welcome to Apple Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c,
Swift 0899bd328a). Type :help for assistance.
1> import Foundation
2> struct A: Codable {
3. var integ
Thanks Youming,
Ok, thanks! I did try that, but I can’t seem to figure out how to make it
actually get used in the decoding process. That being my preferred way, I
tried it first. I chalked it not working up to Swift not knowing which of the
2 init(from decoder:) functions to call, mine or t
Brandon
>JSON’s types effectively end up matching specifically to primitives, of
which there is no mechanism to override the behavior of how a String gets
decoded for instance.
You can override the default behavior with your own custom init(from:)
implementation for your Codable struct:
https://d
Hi Tony,
I like the idea that the type itself is responsible for the conversion. My own
json encode/decode library worked this way and it was really great, however in
trying to leverage Swift4 into it, or to replace it, I just don’t see how
that’s possible given how it’s currently structured.
I’m still not convinced that we should actually provide such a strategy.
Conversions like those below seem like the domain of each type that is being
decoded. If, in a particular type, the “number” can be either a true number or
a string, then that type can try decoding it as one or the other an
Hi Itai,
No problem! Thanks for the heads up. Is there any way I could be involved?
Happy to do the work to whatever guidance your team might have. I’m mostly
just interested in it being there soon, hence volunteering.
Thanks!
Brandon Sneed
From: on behalf of Itai Ferber
Date: Wednesda
Hi Brandon,
Thanks for looking at this! We’ve got plans internally to potentially
add a strategy to `JSONEncoder`/`JSONDecoder` to allow lenient
conversions like this — i.e. implicitly stringify numbers (or parse
them from string input), among some others.
This would be opt-in for consumers of
One downside I see is that the encoder wouldn't know if this specific field
was originally a number instead of a string. If the same Codable struct is
used for GET and POST, for example, the post-encode JSON string could be
invalid because the server expects a number instead of a string for that
fi
Hi everyone,
Just throwing this out to see if anyone else is working on this, or has
opinions/suggestions on how it’s implemented. I’d like to add this to the
Codable/JSONDecoder/JSONEncoder system if no one else is working on it.
Type type conversion, I mean given this JSON payload:
{
17 matches
Mail list logo
