-
Notifications
You must be signed in to change notification settings - Fork 38
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
Labels
enhancement
New feature or request
Comments
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: