binrw icon indicating copy to clipboard operation
binrw copied to clipboard

Extendible ReadOptions (and eventually equiv for BinWrite, maybe)

Open kitlith opened this issue 4 years ago • 0 comments

I've been putting off writing an issue about this for a while >_>

ReadOptions has been referred to as this library's bag of cheats. I have a couple of things I want to tackle there, but I also want users to be able to add their own cheats, for whenever passing something down through arguments would end up either impossible or not very ergonomic.

From now on I'm going to refer to them as Options, as I think they could be useful for both reading and writing.

Motivating Usecases

it just occurred to me that these are both related to FilePtr. FilePtr really is the problem child, eh? :P

FilePtr offsets

FilePtr currently lets you set an offset that gets added to whatever is read as part of the pointer. This is really cool if the offset is consistent throughout the entire file, but a lot of the time it has to change.

However, if we were able to store multiple different offsets, we could give different pointers different types depending on which offset they should be relative to.

FilePtr serialization

Basically, allowing the user to implement it themselves in an ergonomic way. I touched on this briefly in #4 , i want to put a more concrete example in here, but for now i'm too tired to cover it.

Version numbers (new, edited in)

If you have a version number in the header of a file, and it ends up affecting details several layers deep, it would be nice to not have to thread the version number as an argument throughout the entire structure.

Possible Implementation

Last time I was implementing this I came up with the idea of turning Options into a kind of typemap. You have a type, the map stores a value of that type, you index into the map by using the type. Naive implementation involves a heap, complicated type-system abuse can work entirely using the stack. (I wrote https://github.com/kitlith/typemap_core/ for this purpose)

unfortunately the creative solution ends up running into issues once we get to map and maybe parse_with on the macro side of things, though there's almost certainly a way around it, it just compromises cleanliness/ergonomics a bit.

I need to come back to this and give it some more explanation, but for now here's the branch i was implementing things on: https://github.com/kitlith/binrw/tree/option_3

kitlith avatar Apr 03 '21 07:04 kitlith