search

fwcd / swift-binary-coder

Flat, untagged binary serializer for Codable Swift types
https://fwcd.github.io/swift-binary-coder/documentation/binarycoder
MIT License
3 stars 1 forks source link

Cannot re-read input or amend output #4

Open nicklockwood opened 1 year ago

nicklockwood commented 1 year ago

The standard encoder/decoder implementations provided by Apple (e.g. JSONDecoder) allow you to take multiple attempts at reading data in different formats. For example, you could try reading a field as a String, and then handle the error if that fails and try again to read it as an Int.

Similarly you can write to the same output object multiple times with difference objects to get an aggregate output, as in this example: https://gist.github.com/nicklockwood/ff51117ac8139248507ecc84a1ed7fed

Unfortunately this doesn't work with your current BinaryEncoder implementation.

For decoding the problem appears to be that the BinaryDecodingState is shared between containers, which means that once one container has read a value, it's permanently popped from the internal Data object and cannot be read again by another container. This seems like it should be straightforward to fix by using a resettable cursor variable for the current data read position, but I've not attempted to work out a detailed implementation.

For encoding I guess the problem is that you write out the data immediately to the output, making it impossible to add additional fields to the same object using another container. I'm not sure what the solution is there, although this seems like a less common requirement than multiple reads (I only just discovered that it was even possible with JSONDecoder today!).

In any case, it would be great to fix the re-reading limitation in BinaryDecoder at least.

fwcd commented 1 year ago

I agree, the 're-parsing as different types' is something I do too every now and then in manual Decodable implementations and supporting it is definitely a goal. Making the decoder (and the encoder) less stateful also seems like a good idea, even aside from this particular use case.

I'll have to see whether I find some time to fix that soon-ishly, the chances aren't too bad since the cursor-based approach doesn't sound particularly complex to implement, but of course PRs are always welcomed.

(Off-topic, but I've recently stumbled upon your projects on 3D geometry after thinking about whether a Swift DSL for something similar to OpenSCAD would be possible, perhaps even using result builders. Though it's not directly Swift, ShapeScript looks very similar to what I had in mind, so I'll have to dig deeper, definitely looks super interesting!)

nicklockwood commented 1 year ago

thinking about whether a Swift DSL for something similar to OpenSCAD would be possible

Yeah, I'm also working on something like this - probably as an extension of Euclid rather than ShapeScript (Euclid is the underlying 3D library, without the script interpreter).