Hello Itai, Sorry for the confusion, but I understood that the following
> To answer your second question, the reason is that using the protocol implies > that all encoders and decoders must support anything that conforms to that > protocol. We’re not sure this is a reasonable requirement. Many formats do > not have any kind of support for arbitrary size integers, for example. > Therefore, we felt it was best to limit it to a set of concrete types. meant it would actually hinder that kind of transformation or make it more difficult to write custom decoders and encoders. Sorry if I misunderstood that. One follow up question: what would happen if inside the JSON mock object you posted I were to remove the 'address' key (in terms of the produced object and how to access its inner properties)? What would happen if I remove the 'name' one or better if I add another key to the JSON object? Sent from my iPhone > On 26 Apr 2017, at 21:28, Itai Ferber <[email protected]> wrote: > > Hi Goffredo, > > Unless I'm misunderstanding what you mean here, this is exactly what we're > proposing with the API — anything Encodable can encode any type that is > Encodable as a nested value: > > struct Person : Codable { > let name: String > let address: Address > } > > struct Address : Codable { > let street: String > let city: String > let state: String > let zipCode: Int > let country: String > } > > let address = Address(street: "1 Infinite Loop", city: "Cupertino", state: > "CA", zipCode: 95014, country: "United States") > let person = Person(name: "John Doe", address: address) > > let encoder = JSONEncoder() > let payload = try encoder.encode(person) > print(String(data: payload, encoding: .utf8)!) // => {"name": "John Doe", > address: {"street": "1 Infinite Loop", ... } } > > let decoder = JSONDecoder() > let decoded = try decoder.decode(Person.self, from: payload) // => > Person(name: "John Doe", address: ...) > Or have I misunderstood you? > > — Itai > > On 26 Apr 2017, at 13:11, Goffredo Marocchi via swift-evolution wrote: > > > > Sent from my iPhone > >> On 26 Apr 2017, at 17:24, Tony Parker via swift-evolution >> <[email protected]> wrote: >> >> Hi Riley, >> >>> On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution >>> <[email protected]> wrote: >>> >>> I’m sure this has already been discussed, but why are the methods throwing >>> NSErrors and not Enums? If I’m remembering correctly, the original reason >>> for this was because this was meant to be a part of Foundation. Now that >>> this is in the Standard Library, however, it seems strange that we’re still >>> using NSError. >>> >>> Second question that again I’m sure was asked and answered already, but: >>> why do we require implementations for each concrete numeric type (Int, >>> Int8, Int16, Float, etc), instead of using protocols (such as the new >>> Integer protocols)? >> >> To answer your second question, the reason is that using the protocol >> implies that all encoders and decoders must support anything that conforms >> to that protocol. > > Would this make it easier to transform nested JSON into a nested > object/struct? If so it could be useful, very useful. > >> We’re not sure this is a reasonable requirement. Many formats do not have >> any kind of support for arbitrary size integers, for example. Therefore, we >> felt it was best to limit it to a set of concrete types. >> > > I honk we would be missing a trick, unless I am missing something here, that > was very powerful in libraries like Mantle for iOS: the ability to translate > a nested JSON object (some keys in the JSON object having a JSON object as > value, etc...) in an MTLModel subclass composed of other MTLModel subclasses > where doing the transformation of the root object would call the right model > needed to transform for the child JSON objects. > Working with Mantle is safe, rugged (it does not cause crashes if the JSON > file changes), and allows you to break the problem into chunks and present a > coherent simple view to the code that makes use of the instance you created > out of the JSON input. Reference: > https://github.com/Mantle/Mantle/blob/master/README.md > > >> We could change our minds on this before we ship Swift 4, if we feel it was >> the wrong decision. Now that the proposals are accepted we will be landing >> these branches in master soon, which means everyone has a great chance to >> try it out and see how it feels in real world usage before it’s final. >> >> - Tony >> >>> >>>> On Apr 25, 2017, at 3:59 PM, Douglas Gregor via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> Proposal Link: >>>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md >>>> >>>> Hello Swift Community, >>>> >>>> The review of SE-0166 “Swift Archival & Serialization” ran from April >>>> 6...12, 2017. The proposal is accepted with some minor modifications. >>>> Specifically, the core protocols and types will be sunk down into the >>>> Swift standard library for more tight integration with the Swift language >>>> and compiler, and the operations specifically involving Foundation’s >>>> “Data” type will be removed. The proposal document has been updated with >>>> more detail. Thank you everyone for participating in this review! >>>> >>>> - Doug >>>> Review Manager >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
