Last active
May 2, 2020 20:56
-
-
Save skids/cfb129509b0849f50deb to your computer and use it in GitHub Desktop.
packish things
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So, after saying yesterday on IRC that a bottom-up design shoud come first for packish things | |
I somehow came over with a case of hypocrisy and thought a bit about top-downish stuff. | |
Suppose we had a role-like MOP construct (bikeshedding welcome on names): | |
packing foo { | |
template bar { | |
# pack template bottom level constructs | |
# templates can nest, and can come from mixing other packings | |
} | |
} | |
This could be mixed into classes and into grammars. | |
When mixed into a normal class each template would create normal non-packed attributes which the | |
class could then serialize to a buf. This would be needed when we want to mutate non-fixed size | |
things. It would use the template to choose appropriate types/subsets/constraints. A default | |
automatically generated serialization method to produce a buf would be available, and could | |
be overridden/wrapped. | |
When mixed into a CStruct class each template would create accessors to emulate attributes | |
from an underlying buf initializer. This type of class would store in serialized format and | |
only allow mutations that do not necessitate a resize (eventually maybe we could allow shrinking, | |
or adding some padding ahead of time for growing.) It would require a variably-sized | |
CStruct REPR, or maybe we need a different REPR for that, depending on the internals involved, | |
adjust the first sentence of this paragraph accordingly. Importantly it would be possible | |
to get an unmanaged memory object to serve as the storage in case we are mapping a hardware | |
device MMIO or buffer. | |
When mixed into a grammar each template would create a rule that can match a binary structure. | |
There would also be some kind of convenient way to cause that rule to make objects of a | |
corresponding class. | |
This "role" like construct would actually be a bit more MRO than roles, in that there would be a way | |
to prevent rules and attributes from certain roles from being visible, so if you do not want | |
the templates from all sub-packings appearing in your class/grammar you could prune them easily | |
(and thus we need to keep a heirarchy not a flat role list.) This fleibility actually an important thing | |
especially for network formats where simple heirarchy breaks down due to the fact that the encapsulation | |
around a packet does not really fit the "parent" model nicely and you want to be able to treat | |
things received with different encapsulations the same. | |
Oh, also, might want to start keeping a list of various gists people have published on related topics. | |
Let me know if there are others out there. | |
https://gist.github.com/ShimmerFairy/72a25f87939aab077158 | |
https://gist.github.com/Juerd/ae574b87d40a66649692 | |
https://gist.github.com/smls/bc5d0fb42f199574e339 | |
https://gist.github.com/masak/1239203 | |
https://gist.github.com/skids/4998260 # very old, low level types thoughts | |
Also related is jnthn's talk on Grammar::Generative | |
https://www.youtube.com/watch?v=RPQvtfwsilM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Might be worth checking out https://formats.kaitai.io for examples of the sorts of descriptions people might produce.