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

Allow a field to register a "pack_later" function #16

Open
sprout42 opened this issue Oct 14, 2016 · 0 comments
Open

Allow a field to register a "pack_later" function #16

sprout42 opened this issue Oct 14, 2016 · 0 comments

Comments

@sprout42
Copy link
Owner

Some message fields, like a length_in_bytes field (added by #13), should be packed after the field(s) that it references. However, this means that it will need to somehow register a "later" function with the Message object so that when packing it is called after one or more fields are packed.

Perhaps this could be done when the Message object is being validated (in the way noted by #15), so the field can return a list of fields that should be packed before this element. Then the message that is being passed in the pack() function should either allow for an optional extra parameter which is the bytes of the following data (simple, but not quite as much validation as I prefer).

OR, perhaps the Message object could take the supplied dictionary or tuple, and create a new dictionary where the value for every field (key) is a tuple of (original value, bytes) and pass that to the pack() function for each field. That way the field pack could have the original data, AND it could have the bytes for fields which have already been packed. This way if the Message object changes the order that it calls the pack functions the elements themselves now have access to the actual packed data for referenced fields. This could be useful for future functionality, as well as for packing a "bytes length" field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant