[spoonincode]

Change Description

This PR changes boost program option notifiers to fire before plugin initialization instead of after initialization but before startup. Current behavior has bitten me an embarrassing number of times and I’m not immediately sure of any drawback moving the notifiers earlier given our typical plugin pattern.

Using notifiers, IMO, cleans up option handling. For example, without using the notifiers our typical pattern is something like

struct my_plugin_impl {
   std::string server_address;
}

void my_plugin::set_program_options(options_description&, options_description& cfg) {
   cfg.add_options()("https-server-address", bpo::value<string>(), "set the address");
}

void my_plugin::plugin_initialize(const variables_map& options) {
   if( options.count( "https-server-address" )
     my->server_address = options.at("https-server-address").as<string>();
   if(my->server_address.size())
      dothedew();
   //...

But using the notifiers it can be more like

struct my_plugin_impl {
   std::string server_address;
}

void my_plugin::set_program_options(options_description&, options_description& cfg) {
   cfg.add_options()("https-server-address", bpo::value<string>()->notifier([this](const string& a) {
      my->server_address = a;
   }), "set the address");
}

void my_plugin::plugin_initialize(const variables_map& options) {
   if(my->server_address.size())
      dothedew();
   //...

In particular notice that the https-server-address string doesn't have to be copy pastaed around, and that there is no need for the options.at("https-server-address").as<string>(); mouthful.

But the code above won't work today because the notifiers are fired after plugin_initialize() (before startup()). This PR moves the notifiers to occur before plugin_initialize() allowing plugin_initialize() to make use of values set in notifiers.

Change Type

Select ONE

• Documentation

• Stability bug fix

• Other

• Other - special case

Consensus Changes

• Consensus Changes

API Changes

• API Changes

Documentation Additions

• Documentation Additions

[heifner]

LGTM

[kj4ezj]

Makes sense to me

[johndebord]

LGTM.

[revl]

Thanks 👍