I assume this issue affects other implementations of Encoder and Decoder as well. The most obvious way to represent a key with multiple types is an enum, but enums don’t have their conformances to Codable generated automatically. It’s possible to write your own, but it can get a bit ugly (e.g., https://gist.github.com/kenada/9acbd7200cff3590bda5e83118f62523 <https://gist.github.com/kenada/9acbd7200cff3590bda5e83118f62523>).
-- Randy > On Jun 23, 2017, at 1:14 PM, Jon Shier via swift-users > <swift-users@swift.org> wrote: > > Itai: > > No need to apologize, I do appreciate the difficulties of designing this > entire feature as quickly and completely as was required. > > An intermediate JSON type would be a great fix, though most useful if it > exists outside of JSONDecoder so it's useful for encoding as well. As long as > it can be initialize from outside and decoded on its own, I think it could > solve much of that issue. > > > Jo > > On Jun 23, 2017, at 12:54 PM, Itai Ferber <ifer...@apple.com > <mailto:ifer...@apple.com>> wrote: > >> Hi Jon, >> >> I just joined this mailing list and have tried to catch up on the history of >> this thread, so please excuse me if I’ve missed something. >> >> I’m sorry the Codable API at the moment does not answer your needs — you’re >> clearly not the only one who’s run into this, so let’s see how we can work >> together to make the API better for everyone. >> For one thing, in the case of grabbing a subtree of JSON as "unevaluated" or >> "unmapped" (as it appears to be in the metadata case), it should be fairly >> simple to add a JSONDecoder.UnevaluatedJSON type that will allow you to >> essentially decode that part of the tree as an Any. JSONDecoder would have >> knowledge of this type and would be able to return the subtree inside of it >> — you’d decode a property as JSONDecoder.UnevaluatedJSON.self and access the >> contents through var value: Any?, or something similar. This would be simple >> additive API, which although might not make it in the upcoming betas, should >> be fairly simple introduce. Would this solve that use case? >> >> We’re also working on improving NSISO8601DateFormatter. I don’t think I saw >> it in any of your emails — what specific use case are you looking for that >> it doesn’t at the moment support? >> >> — Itai >> >> On 23 Jun 2017, at 9:24, Jon Shier via swift-users wrote: >> >> David: >> I never called the design silly (though I think it’s inadequate for >> some important usage and makes some strange decisions), I was referring to >> the fact that the (apparent) official solution can’t actually decode all of >> the JSON people use. It’s the same reason I brought up >> NSISO8601DateFormatter. After years of using third party libraries or >> writing your own, limited, implementation, finally, finally there was an >> official solution from Apple. The official 8601 date formatter. Only, come >> to find out, it doesn’t actually handle all of 8601 and those third party >> libraries or custom implementations are still required if you venture >> outside supported scenarios. I’m concerned about the same thing happening >> here. Now, if JSONDecoder isn’t actually intended to serve as a general JSON >> parsing solution, which I think would be surprising to a lot people, then >> fair enough. Apple and the Swift team just need to be far more clear that >> that’s the case, rather letting everyone believe otherwise. And frankly, if >> that’s the case, I think a huge opportunity has been missed. At the same >> time, if / when an official solution for JSON parsing comes out, or an >> actual JSON representation, how will it interact with the previous >> implementation? >> These concerns, and the general concerns I expressed during the >> evolution review (which still exist) aside, this is fixable, if the Swift >> team is interested in doing so. However, if the limitations of JSONDecoder >> aren’t even seen as limitations, or interest in fixing them aren’t there, >> then there’s little point to continuing the discussion. Something as simple >> as an additional decode(_ type: from: Any) on JSONDecoder would solve the >> issues with decoding partially deserialized blobs or representations from >> other APIs. Something to help represent Any in Codable types might be >> useful, though I recognize that there isn’t any way to currently >> differentiate between Codable types and those just used by JSON. >> All of that said, my concerns mainly lie within the JSON realm. Codable >> works great for serialization to disk or other scenarios where I can just >> deal with the Data result and not have to worry about weakly typed >> intermediate results. I’ll certainly be using it everywhere I can. And I’m >> super happy that conformance is generated by the compiler rather than >> manually, like we had to do with Objective-C for over a decade. Even the >> JSON side is useful if I can control both sides of the API, which makes >> Swift on the server very powerful. >> So if I seem overly strident in my expression here it’s because I >> experience the pain of consuming poorly designed JSON in Swift on >> practically a daily basis and had hoped that a native implementation would >> alleviate that. That it doesn’t, for me and others, currently, is very >> disappointing. That the Swift team doesn’t seem to see the current >> limitations as important or at all is doubly so, since it seems like these >> issues will never be fixed. >> >> >> >> Jon >> >> >>> On Jun 23, 2017, at 4:34 AM, David Hart <da...@hartbit.com >>> <mailto:da...@hartbit.com>> wrote: >>> >>> >>> On 23 Jun 2017, at 03:45, Jon Shier via swift-users <swift-users@swift.org >>> <mailto:swift-users@swift.org>> wrote: >>> >>>> I’m sorry, are you complaining about my use of Codable instead of more >>>> precisely referring to the JSON endcode/decode functionality based on it >>>> in Foundation, or are you honestly trying to say that said functionality >>>> was never intended to be a general purpose JSON solution? If it’s not >>>> actually intended to handle all JSON you should probably call it something >>>> else. >>> >>> Hi Jon, >>> >>> First of all, I'd like to point out that I've found your tone to be quite >>> rude. Calling the design of Codable, that has gotten a lot of work from >>> Apple and swift-evolution, as silly is insulting and can leave people hurt. >>> If you have found it lacking, please say so: we're all here to discuss any >>> feedback people have had with Swift. But please do so with respect for the >>> people and the work behind it. >>> >>> Now, concerning Codable, I find its name quite apt. It was never intended >>> to be used a full JSON parser but as a strongly-typed Swift equivalent of >>> Objective-C's NSCoding, which is nothing more than a framework for >>> serializing and deserializing types into different file formats. >>> >>> David. >>> >>>> Jon >>>> >>>>> On Jun 22, 2017, at 9:42 PM, Greg Parker <gpar...@apple.com >>>>> <mailto:gpar...@apple.com>> wrote: >>>>> >>>>> >>>>>> On Jun 22, 2017, at 6:00 PM, Jon Shier via swift-users >>>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >>>>>> >>>>>> My main concern here is that, as Swift’s official JSON parsing method, >>>>>> Codable should be able to handle any JSON representation and use and it >>>>>> doesn’t. >>>>> >>>>> Is this true? Is Codable intended to be Swift's official JSON parsing >>>>> system? Is Codable intended to be a general-purpose JSON parsing system? >>>>> >>>>> My understanding was that Codable was designed to serialize Swift types, >>>>> not to be able to import arbitrary JSON text into Swift nor to >>>>> interoperate with every existing JSON API. >>>>> >>>>> >>>>> -- >>>>> Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime >>>>> Wrangler >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> swift-users mailing list >>>> swift-users@swift.org <mailto:swift-users@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-users >>>> <https://lists.swift.org/mailman/listinfo/swift-users> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org <mailto:swift-users@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-users >> <https://lists.swift.org/mailman/listinfo/swift-users> > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
