params: fix consensus config string representations

[roysc]

These should at least indicate whether the object is nil.

[holiman]

Any particular reason? I don't think it's the "norm" for objects that implement Stringer to handle nil.

[karalabe]

I don't think this is a good change. We want to see what's active, not what's not active. In this particular case, there's no value displaying all the different consensus mechanisms that are not used.

[karalabe]

Or if we're misunderstanding something, please give an example where this is happening and what's wrong / what you would like to see.

[roysc]

Right, I should have explained. The main use case for me is debugging. Just to be clear, all this does is avoid ambiguity.

Currently this chain config:

{
  "chainId": 1212,
  "homesteadBlock": 0,
  "eip150Block": 0,
  "eip155Block": 0,
  "eip158Block": 0,
  "byzantiumBlock": 0,
  "constantinopleBlock": 0,
  "petersburgBlock": 0,
  "istanbulBlock": 0,
  "berlinBlock": 0,
  "londonBlock": 0,
  "mergeNetsplitBlock": 0,
  "terminalTotalDifficulty": 0,
  "shanghaiTime": 0,
  "cancunTime": 0
}

when printed with %+v, shows as (note ... Ethash:ethash Clique:clique} at the end)

&{ChainID:+1212 HomesteadBlock:+0 DAOForkBlock:<nil> DAOForkSupport:false EIP150Block:+0 EIP155Block:+0 EIP158Block:+0 ByzantiumBlock:+0 ConstantinopleBlock:+0 PetersburgBlock:+0 IstanbulBlock:+0 MuirGlacierBlock:<nil> BerlinBlock:+0 LondonBlock:+0 ArrowGlacierBlock:<nil> GrayGlacierBlock:<nil> MergeNetsplitBlock:+0 ShanghaiTime:0x14000312da0 CancunTime:0x14000312da8 PragueTime:<nil> VerkleTime:<nil> TerminalTotalDifficulty:+0 Ethash:ethash Clique:clique}

With this change, we get ... Ethash:<nil> Clique:<nil>.

If we add a clique key to the config:

{
  "chainId": 1212,
  "homesteadBlock": 0,
  "eip150Block": 0,
  "eip155Block": 0,
  "eip158Block": 0,
  "byzantiumBlock": 0,
  "constantinopleBlock": 0,
  "petersburgBlock": 0,
  "istanbulBlock": 0,
  "berlinBlock": 0,
  "londonBlock": 0,
  "mergeNetsplitBlock": 0,
  "terminalTotalDifficulty": 0,
  "shanghaiTime": 0,
  "cancunTime": 0,
  "clique": {
    "period": 5,
    "epoch": 30000
  }
}

...we'll currently get an identical string to the first one. Is that really what we want?
With the change it shows ... Ethash:<nil> Clique:clique { period: 5, epoch: 30000 }}

Any particular reason? I don't think it's the "norm" for objects that implement Stringer to handle nil.

That's true, but the norm is to define String on a value receiver. Actually, that's what I should have done here, then Stringer would automatically show <nil> for nil fields. I'll change it.

I don't think this is a good change. We want to see what's active, not what's not active. In this particular case, there's no value displaying all the different consensus mechanisms that are not used.

Not sure I follow? With this change it should be more clear which engines are and are not active.

[roysc]

If you don't mind, I'll open a revised PR with a better explanation.