Sent from my iPad
> On Apr 12, 2017, at 2:53 AM, piotr gorzelany via swift-evolution > <[email protected]> wrote: > > For me it boils down to a question if Data is the best type to represent > JSON. Data is really generic, you could serialize an UIImage into data and > pass it to the decoding function. Data is what you read from and write to disk and network and therefore the appropriate choice for these APIs. > > Yes, JSON is not a very strong type but that is the nature of JSON, it is a > dynamic data structure like a dictionary. But giving it a type gives us > future flexibility to extend it if needed. > > Also, raw JSON manipulation is common practice since the server does not > always give you the perfect JSON to deserialize into a model object. > > Say you have a model object with some nested objects in it. To initialize > them from JSON you will need to full JSON for all the objects. But the common > practice is that the server will return only the full top level object and > IDs for the nest d objects so you fetch them separately. > > W dniu pon., 10.04.2017 o 22:47 Jordan Rose <[email protected]> > napisał(a): >> >>>> On Apr 10, 2017, at 02:52, David Hart via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> This is a really great proposal. As an iOS developer I work with JSON >>>> almost every day since most mobile apps communicate with a backend through >>>> JSON messages. It's good to see that better JSON support is coming to >>>> Foundation so we don't have to rely on third party libraries. >>>> >>>> That being said, there is one thing I don't like which is that the JSON >>>> encoding function returns Data and the decoding function takes Data. >>>> >>>> It would be really great if the Foundation team could introduce a >>>> dedicated type of JSON. >>>> There are several advantages of working with a dedicated type. >>>> - The underlying data is always valid JSON >>>> - You can extend this type in the future with helper methods for >>>> manipulating JSON >>>> - It makes it explicit what you are dealing with >>>> >>>> A good analogy is the URL type. You could represent an URL with a String >>>> or Data type, but by introducing a dedicated type you have the full >>>> advantages mentioned above. Data on the other hand is like a generic >>>> container which you cannot easily extend with URL or JSON specific methods. >>>> >>>> Having a dedicated JSON type is also one of the reasons third party >>>> libraries like SwiftyJSON are so popular. It makes it super easy to >>>> manipulate JSON structures. And sometimes developers like would like to >>>> manipulate JSON directly. >>> >>> I don’t think it would be a good thing to have this in Foundation. >>> Foundation needs to push developers towards adopting best practices, and >>> manipulating JSON directly instead of going through Codable’s strong-typing >>> is not necessarily recommended. I’m not saying it doesn’t have its uses. >>> But it’s usefulness is definitely narrow now once we have Codable. I think >>> this is something that should stay in a third-party library. >> >> I haven't thought heavily about this, but the thoughts that I have say that >> JSON just isn't a good type in Swift. It's not an efficient in-memory >> representation and it's not a convenient structural representation (because >> of the use of either 'Any' or 'JSON' in the recursive position). I'll admit >> that sometimes you're handed some JSON and you want to extract a little bit >> of information out of it without building a typed representation of the >> whole thing, but that still seems like something that doesn't need to be the >> common path. >> >> Jordan >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
