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

Change ChainEpoch and TokenAmount types #309

Merged
merged 3 commits into from
Mar 28, 2020
Merged

Change ChainEpoch and TokenAmount types #309

merged 3 commits into from
Mar 28, 2020

Conversation

austinabell
Copy link
Contributor

Summary of changes
Changes introduced in this pull request:

  • Since no methods on these types or any need for it, changes to aliases to not require to manually implement traits and wrap underlying types

Reference issue to close (if applicable)

Closes

Other information and links


/// Wrapper around a big int variable to handle token specific functionality
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This serializes properly? Having a biguint wrapped in a tuple struct is serialized differently... Though i dont know if we have any interop test wrt to that

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I have no idea what specifically you are talking about because there are no new serializations that are added in this PR, I'll assume you mean the BigInt serialization wrappers that were introduced in #295. Yes, of course there are interop serialization tests, such as the message serialization vectors which includes two TokenAmounts and the test you wrote that tests the serialization of that one blockheader which includes uses this same wrapper type to name just a few.

This literally doesn't matter if it's wrapped because the serialization implementation is custom, but even if it was, like in the case of TokenAmount with the annotation before this change, then it still serializes as the parameter if there is only one parameter. Remember when you had to serialize VRFProof in blockheader as a 1 length array because of this?

@austinabell austinabell merged commit 661f52a into master Mar 28, 2020
@austinabell austinabell deleted the austin/aliases branch March 28, 2020 20:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants