[x] write functions create a new DataView object each time. should we be using a shared DataView to do operations?
EDIT for the above task (08/17/2024):
My understanding is that this is not possible at the moment. My initial suspicion was that this was the way to go, especially due to the serial nature of the data, we don't have to worry about concurrency issues that arise when sharing a write buffer.
However, the main problem would be resizing the ArrayBuffer to varying byteLengths. This is completely possible, but it is a relatively new feature. Since the runtime is currently not transpiled with Babel and we'd like to target older browsers, I don't think is afforded to us.
So, I'll stick to creating a new ArrayBuffer and DataView for each write. I ask that reviewers take special note of this and verify my findings. I welcome any corrections or suggestions.
TODOs:
tested on one ksy file that only uses u1, u2, u4, and s2 for primitive data types.
used with a very rough draft of the compiler on the fork here: https://github.com/laura-a-n-n/kaitai_struct_compiler/compare/serialization...laura-a-n-n:kaitai_struct_compiler:javascript-serializer
possible flaws / areas for improvement:
EDIT for the above task (08/17/2024):
My understanding is that this is not possible at the moment. My initial suspicion was that this was the way to go, especially due to the serial nature of the data, we don't have to worry about concurrency issues that arise when sharing a write buffer.
However, the main problem would be resizing the ArrayBuffer to varying byteLengths. This is completely possible, but it is a relatively new feature. Since the runtime is currently not transpiled with Babel and we'd like to target older browsers, I don't think is afforded to us.
So, I'll stick to creating a new ArrayBuffer and DataView for each write. I ask that reviewers take special note of this and verify my findings. I welcome any corrections or suggestions.
There's probably a better solution.