Parsing Excel Spreadsheets with Swift's Codable Protocols

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by conradev on Monday November 12, 2018 @04:29PM (#18436025)

The one thing I don't love about Swift's Codable is the lack of customizability in the "magic" part: the part where the compiler generates the Encodable/Decodable implementations. Most notably, the compiler can't generate implementations for enums. The only thing that Swift supports customizing without fully implementing the methods for Encodable and Decodable is the name of the keys, using a custom CodingKeys type.

Serde, an equivalent third-party crate in Rust, supports a lot of customization which I find invaluable. It can (de)serialize values like this with ease:

    {"type": "location", "value": {"latitude": 0, "longitude": 0}}

in a very small amount of code:

    #[derive(Serialize, Deserialize)]
    #[serde(tag = "type", content = "value")]
    #[serde(rename_all = "lowercase")]
    enum Value {
        Location { latitude: f64, longitude: f64 },
        String(String),
        ...
    }

Serde also supports customizing serialization on a per-field basis without having to implement the entire protocol, which is nice:

    #[derive(Deserialize, Serialize)]
    struct Record {
        #[serde(with = "chrono::serde::ts_seconds")]
        updated: DateTime<Utc>
    }

I really hope that Swift has better ways (like the above) to customize Codable in the future. I find myself implementing the protocol myself in 90% of cases, whereas I very rarely have to do that for Serde.

[ Parent | on HN ]

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by wild_preference on Monday November 12, 2018 @09:14PM (#18437878)

Serde offers more out of the box functionality with its annotations, but it's also bit uglier than Swift's Codable when you do need to implement it yourself.

If it wasn't for a blog post that gave some simple examples, I couldn't even figure it out myself.

Possibly not fair to compare them this way, though. No clue what the trade-offs are.

[ Parent | on HN ]

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by conradev on Tuesday November 13, 2018 @10:18PM (#18447184)

That's very fair criticism. Implementing custom serde serializers is painful, but thankfully I only have to do it in rare circumstances.

[ Parent | on HN ]

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by maxdesiatov on Monday November 12, 2018 @06:00PM (#18436797)

The main reason for that is lack of hygienic macros in Swift. Currently you can use code generation tools like Sourcery and SwiftGen, but I expect 1st-class meta-programming support to come after Swift 5.0 release. After ABI stability I imagine macros are pretty high on the priority list of the core team.

[ Parent | on HN ]

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by conradev on Monday November 12, 2018 @06:42PM (#18437025)

They might also go in the opposite direction and add runtime APIs to construct types dynamically. Various initiatives (like the Python interop for TensorFlow) are pulling Swift in that direction:

https://github.com/apple/swift-evolution/blob/master/proposa...

[ Parent | on HN ]

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by slavapestov on Monday November 12, 2018 @07:08PM (#18437168)

I have a hard time envisioning full-fledged macros coming to Swift, but moving Equatable/Hashable/Codable synthesis to a library should be possible with more restricted meta-programming capabilites. See Joe Groff's talk for details: https://www.skilled.io/u/swiftsummit/swift-s-reflective-unde...

[ Parent | on HN ]

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by saagarjha on Monday November 12, 2018 @11:49PM (#18438676)

> I have a hard time envisioning full-fledged macros coming to Swift, but moving Equatable/Hashable/Codable synthesis to a library should be possible with more restricted meta-programming capabilites.

I've heard many people on the mailing lists talk about wanting to add hygienic macros–so when you're talking about "full-fledged macros", are you talking about unhygienic or hygienic ones?

> See Joe Groff's talk for details

I'm actually curious how much is possible, in terms of reflection capability, both currently and in the future. How close can I get to the dynamism of say the Objective-C runtime? Can I grab a function pointer knowing its mangled name? Can I list every class in a binary by consulting the runtime metadata? Can I "swizzle"?

[ Parent | on HN ]

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by slavapestov on Tuesday November 13, 2018 @12:13AM (#18438772)

> How close can I get to the dynamism of say the Objective-C runtime?

Well, right now the compiler emits a lot of metadata that is mostly used for runtime generics, dynamic casting, and the (somewhat limited) Mirror type. But these features have enough generality that a surprising amount of stuff has to be encoded. However there’s no nice API for looking at it yet.

> Can I grab a function pointer knowing its mangled name?

That’s just dlsym().

> Can I list every class in a binary by consulting the runtime metadata?

The metadata is there, but there’s no exposed API for doing this.

> Can I "swizzle"?

There’s an experimental thing for this now: https://github.com/apple/swift/pull/20333

[ Parent | on HN ]

Re:Parsing Excel Spreadsheets with Swift's Codable Protocols by saagarjha on Tuesday November 13, 2018 @12:33AM (#18438836)

> > Can I grab a function pointer knowing its mangled name?

> That’s just dlsym().

Sorry, I should have been more clear: can I grab a function pointer to an unexported function?

> > Can I "swizzle"?

> There’s an experimental thing for this now: https://github.com/apple/swift/pull/20333

This is interesting; I haven't been really been following the lists recently but I took the time to read the linked thread and the pull request. While the functionality contained in the pull request is interesting, it's not quite the same as swizzling since it's done unconditionally at load time rather than runtime (so it's much more similar to DYLD_INTERPOSE in that sense). While this covers many of the cases when swizzling is necessary, it leaves out a rather important one where the correct method override is selected at runtime, generally conditionally.

Also, as a sidenote, it seems that there is some sort of motivation to have compiler type checks for the replacement, i.e. @_dynamicReplacement(for: bar())–how will this actually work in practice? If I compile a bundle without access to the source of the application I'm going to be loaded into, how would bar() be accessible to the compiler at all?

[ Parent | on HN ]