deserialization & validation

[woolie]

In the code I have been writing that uses the deserialization extensively, I have found a need to validate the results post deserialization.

I forked and started working on a rough layout of how this would happen.

Basically, everywhere there is deserialization there would be an optional second step that validated the deserialized results, which could potentially throw a validation error.

The default implementation would do nothing and never throw.

Any thoughts on this?

Here is an example (just a rough sketch):

public struct Track: XMLIndexerDeserializable {
    var id: Int

    public var name: String
    public var shortName: String
    public var color: [Int]

    public var playingStyle: PlayingStyle
    public var palmMute: Double                // 0-1 (percent)

    public static func deserialize(_ node: XMLIndexer) throws -> Self {
        let colors: String = try node["Color"].value()
        let colorsArray = colors.split(separator: " ")

        return try Track(
            id: node.value(ofAttribute: "id"),
            name: node["Name"].value(),
            shortName: node["ShortName"].value(),
            color: colorsArray.compactMap { Int($0) },
            playingStyle: PlayingStyle.withString(node["PlayingStyle"].value()),
            palmMute: node["PalmMute"].value(),
        )
    }

    public static func validate() throws {
        if color.count > 3 { throw TrackValidation.tooManyColorValues() }
        if palmMute < 0.0 || palmMute > 1.0 { throw TrackValidation.palmMuteOutOfRange() }
    }
}

[drmohundro]

Meant to reply earlier... I like the idea. Let me throw some thoughts out and see what sticks:

• it if throws an error, would you still want the instance that was deserialized, even if it was invalid?
• I guess, if a validate method isn't provided, then it just assumes it is valid?
• the validation exception would be up to the implementation to provide, right?

[woolie]

I have a fork with it implemented. I can push a PR and let you see. Let me clean it up some more with tests so you get the idea.

Answers to your questions:

• Not deserialized if invalid
• no implementation returns valid
• yes, just like the deserialize errors

I'll head upstairs to work and will send you a PR for review (not for merging, just for you to think about).

[woolie]

I pushed the concept changes into a PR. NB: I fixed all of the linting issues I caused, but it seems there are some that were there from before.