DEPENDENT: Policy: Turn policy globals into CStandardPolicy attributes #6423
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.
Includes #6068 but has been separated from it to hopefully accelerate things.
This separates the CPolicy interface from a CStandardPolicy reference implementation that initializes its attributes on init from command line options (it is friendly to GUI configuration as specified by @luke-jr ).
This doesn't introduce any new file (no globals/policy.o), any factory or container, any command line option or anything. Functionally, it just moves the a couple of relay help message options to a new policy group (where all relay options should end up).
But...if it's functionally equivalent...why eliminate globals from main.cpp ?
Because...http://lmgtfy.com/?q=why+globals+are+wrong ...sorry, because...http://c2.com/cgi/wiki?GlobalVariablesAreBad http://programmers.stackexchange.com/questions/148108/why-is-global-state-so-evil of many reasons.
I understand that elimination several variables to put them together so that explicitly take them as parameters by all functions that need it is not a priority since it doesn't functionally modify bitcoin core.
On the other hand, introducing new policy options as attributes to a class that it's sometimes used as a global (like CChainParams, what we started with it should be what we have in mind for CPolicy) is preferable to introducing a brand new global variable in main. But that won't be possible until we introduce something like Policy::AppendHelpMessages() and CPolicy::InitFromArgs(), and more globals that are low priority to clean up keep accumulating in main.o.
So, in summary, why do this?
To give the opportunity to new PRs not to unnecessarily give us more global cleanup work when they're created.
Also (although I'm not going to continue that GUI part), making policy options GUI-configurable (and hopefully, in the future all new existing and new options "for free") would be very nice too.
The way I've understood this from @luke-jr, with Policy::AppendHelpMessages() and CPolicy::InitFromArgs() it is relatively easy to create a generic GUI that doesn't require any more work outside those methods to introduce new policy attributes.