Continuing the discussion from Idea: Exposing _JSONEncoder and _JSONDecoder functionality:
Back in July, 2017, @itaiferber mentioned the possibility of exposing a
StructureEncoder and a
StructureDecoder that would work similarly to
JSONDecoder with the exception that they would not perform the final/initial steps of serializing to and from JSON.
I find this functionality tremendously helpful, so I hope to revive the discussion about this possibility by giving a shot at an implementation.
So, one question I have about swift development in general: My current implementation lives here: https://github.com/mortenbekditlevsen/swift/tree/structureencoder
Am I free to create a WIP PR against swift/master even though I haven’t discussed this with anyone yet? Or do random PRs like this somehow ‘pollute’ anything for anyone?
More general questions:
- Do anyone else see a benefit in having this
My personal use case is the Firebase real-time database from Google. The APIs for storing and retrieving data accept and return
Anyvalues containing exactly such JSON-ish data structures.
- With regards to the API for this. Does it seem alright to basically duplicate the API for
In my oppinion I think that it does, and that it is nice to deal with a familiar API.
Questions that I have encountered in implementing this:
Should a possibly future
StructureDecoderlive in the same file as the corresponding
JSONDecoder. They share the implementation details (
_JSONDecoderwhich are currently
private, but these could of course be made
In the current implementation they do live in the same file.
With regards to the currently
_JSONDecoder: Should they still be named in this way even though they are now the base of two types of encoding/decoding?
In the current implementation I have not done any renaming.
With regards to the options for
StructureDecoder, then the options of
JSONDecodercan be used as they are - with exception of
JSONEncoder.OutputFormattingwhich do not make sense for
The ‘cloned’ options could either be typealiases for the corresponding
JSONDecoderoptions, or they could be completely separate enumerations.
In the current implementation I have chosen to model them as new enumarations with the exact same structure, and then expose a property that can return the
JSONDecoderversion of the options to be passed on to
I think that this nicely hides the fact that the implementation details are currently shared.
Are there any assumptions in the
_JSONDecoderabout the possible values and types that can be present due to the knowledge that the
JSONSerializationwas the only source of input for the
I feel that there may be…
JSONEncoder, top level fragments are not allowed. Should ‘top level values’ be allowed in
In the current implementation top level values are allowed since I could find no good argument to disallow them.
I have basically cloned all tests from
TestJSONEncoder.swiftto a new
TestStructureEncoder.swiftfile. I have removed a few tests that relate to formatting, and change the ones that verify that top level fragments are disallowed. For the main workhorse of the test file, I have skipped the equality check of the intermediary value, since the intermediary format is a value of type
Anyand it’s hard to test for equality when one value may be an
NSDictionaryand the other may be a
Dictionary. I think that it is fair to skip this extra test step, since the complete round trip is still tested. Is this an acceptable approach to testing this?
I look forward to seeing any comments on this.