common: drop BigMin and BigMax, they pollute our dep graph #30645
Conversation
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
karalabe
requested review from
lightclient,
s1na,
holiman and
rjl493456442
as code owners
MariusVanDerWijden
approved these changes
Oct 21, 2024
karalabe
force-pushed
the
common-nobigminmax
branch
from
4a72bab to
9734568
Compare
holiman
pushed a commit
that referenced
this pull request
Nov 19, 2024
Way back we've added `common.math.BigMin` and `common.math.BigMax`. These were kind of cute helpers, but unfortunate ones, because package all over out codebase added dependencies to this package just to avoid having to write out 3 lines of code. Because of this, we've also started having package name clashes with the stdlib `math`, which got solves even more badly by moving some helpers over ***from*** the stdlib into our custom lib (e.g. MaxUint64). The latter ones were nuked out in a previous PR and this PR nukes out BigMin and BigMax, inlining them at all call sites. As we're transitioning to uint256, if need be, we can add a min and max to that.
zfy0701
pushed a commit
to sentioxyz/go-ethereum
that referenced
this pull request
Dec 3, 2024
…30645) Way back we've added `common.math.BigMin` and `common.math.BigMax`. These were kind of cute helpers, but unfortunate ones, because package all over out codebase added dependencies to this package just to avoid having to write out 3 lines of code. Because of this, we've also started having package name clashes with the stdlib `math`, which got solves even more badly by moving some helpers over ***from*** the stdlib into our custom lib (e.g. MaxUint64). The latter ones were nuked out in a previous PR and this PR nukes out BigMin and BigMax, inlining them at all call sites. As we're transitioning to uint256, if need be, we can add a min and max to that.
19 tasks
gzliudan
added a commit
to gzliudan/XDPoSChain
that referenced
this pull request
Dec 19, 2024
gzliudan
added a commit
to gzliudan/XDPoSChain
that referenced
this pull request
Dec 21, 2024
gzliudan
added a commit
to gzliudan/XDPoSChain
that referenced
this pull request
Dec 26, 2024
gzliudan
added a commit
to gzliudan/XDPoSChain
that referenced
this pull request
Dec 28, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Way back we've added
common.math.BigMinandcommon.math.BigMax. These were kind of cute helpers, but unfortunate ones, because package all over out codebase added dependencies to this package just to avoid having to write out 3 lines of code.Because of this, we've also started having package name clashes with the stdlib
math, which got solves even more badly by moving some helpers over from the stdlib into our custom lib (e.g. MaxUint64). The latter ones were nuked out in a previous PR and this PR nukes out BigMin and BigMax, inlining them at all call sites.As we're transitioning to uint256, if need be, we can add a min and max to that.