-
Notifications
You must be signed in to change notification settings - Fork 62
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
add MustFromBig
for nicer struct initialization
#128
Conversation
Actually, might have been nicer to just call FromBig and handle the return, more future proof. |
You mean in this PR or from your side? |
Actually, I'm thinking that if you're in this case:
And let's say we know nothing about So wouldn't you rather have a |
Codecov Report
@@ Coverage Diff @@
## master #128 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 5 5
Lines 1538 1543 +5
=========================================
+ Hits 1538 1543 +5 |
Not really, all these data are already parsed from disk or network into uint256, only the tx interfaces are still using big.Int and I don't want to overhaul all the interfaces for the blob pool. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
MustFromBig
for nicer struct initialization
The PR #128 added MustFromBig, this PR adds two similar helpers: MustFromHex and MustFromDecimal. // MustFromHex is a convenience-constructor to create an Int from // a hexadecimal string. // Returns a new Int and panics if any error occurred. func MustFromHex(hex string) *Int // MustFromDecimal is a convenience-constructor to create an Int from a // decimal (base 10) string. // Returns a new Int and panics if any error occurred. func MustFromDecimal(decimal string) *Int
This PR allows the second form (last two lines) along side the current form (first two lines) of initializing new ints from bigs.
Panics can only be captured when a goroutine is unwinding, hence why the messy construct in the tests. Also, it would have been a tad cleaner to wait on the panic with
sync.WaitGroup
vs a channel, but the channel approach introducing a dependency onsync
.