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> 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
https://lists.swift.org/mailman/listinfo/swift-users
