Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extendible ReadOptions (and eventually equiv for BinWrite, maybe) #24

Open
kitlith opened this issue Apr 3, 2021 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@kitlith
Copy link
Collaborator

kitlith commented Apr 3, 2021

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

csnover added a commit to csnover/binrw that referenced this issue Sep 7, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 10, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 11, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 11, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 11, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 11, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 11, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 12, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 12, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 14, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Sep 18, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 13, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 13, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 14, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 15, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 15, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 15, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 15, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 15, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 15, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 15, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 16, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
csnover added a commit to csnover/binrw that referenced this issue Nov 16, 2022
Assuming jam1garner#24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
jam1garner pushed a commit that referenced this issue Nov 16, 2022
Assuming #24 will not be implemented any time soon,
since there is no longer any need to pass through anything except
endianness, remove the overhead of having an extra object that only
carries endianness.
@csnover csnover added the enhancement New feature or request label Sep 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants