Skip to content

Conversation

@jtimon
Copy link
Contributor

@jtimon jtimon commented Jul 11, 2015

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.

@jtimon jtimon changed the title Policy: Turn policy globals into CStandardPolicy attributes DEPENDENT: Policy: Turn policy globals into CStandardPolicy attributes Jul 11, 2015
@jtimon jtimon closed this Jul 11, 2015
@jtimon jtimon force-pushed the policy-args-0.11.99 branch from 2cb11b8 to 7cdefb9 Compare July 11, 2015 18:41
@jtimon jtimon reopened this Jul 11, 2015
@jtimon jtimon closed this Jul 11, 2015
jtimon added 3 commits July 22, 2015 22:55
…y class implementing it

Rename 3 functions into CPolicy methods:

- IsStandard -> policy.ApproveScript
- IsStandardTx -> policy.ApproveTx
- AreInputsStandard -> policy.ApproveTxInputs
...by separating CStandardPolicy implementation from CPolicy interface

Eliminated globals:

-fIsBareMultisigStd
-fRequireStandard
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant