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:
```swift
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
