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.
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
config: use default fork config if not specified in config.toml #1654
config: use default fork config if not specified in config.toml #1654
Changes from all commits
27c52b9
5c06505
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I do not think this is the right way to do it, there is something called
reflect.VisibleFields
in go. Where you could iterate throughg.Config
struct and in one loop add default value in case is nil. If you change this to use this functionality, then it would automatically update in case of new param in config and no additional change would be requiredThere 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.
Just curious how could we achieve the goal of automatically update? , it seems that by using reflect.VisibleFields, it still need to use 'if' to compare the fieldName and check its value, and then set the default value (BlockNumber) if nil.
Another minor comments is that reflection seems to be a little hard to maintain as it kind of
wrap
the type of the field when trying to access it's value, and also the rule ofsettable
. which imbo becomes error-prone for developers when something new is added toChainConfig
.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.
We can achieve that we do not need to add new value here in case of new HF block or am I missing something?
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.
@sunny2022da but maybe you are right about settable rule and this just complicates things :/
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.
@sunny2022da We can compare field names by converting them to string using reflection. Then for each field name of
g.Config
we look up the value of that field indefaultConfig
using the string as a key. Then through reflection we can set the value of the field ing.Config
.Basically we need to create two intermediate maps that allow us to look up block names as keys to the maps.
This is actually similar to how geth maps RPC method names like
eth_gasPrice
to callbacks such asfunc GasPrice(..)
.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.
got you~ So it seems to me the logic is:
field = fields[i]
, compare the fieldName and the name ofHF block
, such asHomesteadBlock
, then get the value of the field.it seems to me that the logic is a little bit complicated then the one we currently have.
Moreover, I think the reason that geth use reflection for mapping RPC calls is because there's serialization/de-serialization involved in the RPC case, where reflection is a good choice to get the method name.
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.
You are more or less right. You can do it all in one for loop. You iterate over the fields of
g.Config
, and if the value is nil, you retrieve using the map structure the matching block indefaultConfig
, and update the field's value.If you use this map you don't need to add an if statement for each block name since the key of the map will find you the matching block from
defaultConfig
.I think this logic is not that complicated, and even if the code ends up being complicated, the user experience and maintainability are much better as we wouldn't need to keep updating this code every time there is a new hard fork.
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.
Correct, we just need to maintain the map you mentioned in this way, adding new <k,v> pair when there is new HF added.
So the problem remain to whether we decide to use reflection here, Let hear others~
Thx for explanation!
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.
So this PR should add default config values if not specified in config.toml. In this case why reinventing the wheel and not use a config package which is already tested?
ex 1: https://github.com/gookit/config
ex 2: https://pkg.go.dev/github.com/ardanlabs/conf/v3#hdr-Example_Usage
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.
Thank for all your comments, I think the main point is whether to improve the code by reflect.
I would prefer the if/else logic, since:
1.could avoid the complexity of reflection
2.the extra KV map mentioned by @Mister-EA could bring big change to the current HF setup. e.g. the code in: params/config.go