PoC: config reading with state v2

[poslegm]

My next attempt to implement config reading with state. Based on #88 and @kitbellew's ConfigDecoderFactory idea.

Now it presents independent ConfigReaderDecoder typeclass with main API

def decoder: S => ConfDecoder[A]

where S is state provided on decoder construction (like default values for collections).

It still has priority implicits magic but with improvements:

1. safe methods for map/orElse/etc on ConfDecoderReader without state loss
2. doesn't break ConfDecoder API and already created decoders
3. No inheritance from ConfDecoder

I defined ConfDecoderReader instances for Map[String, A] and Iterable[A] with ability to .add to defaults. It's possible to implement .remove also.

S type parameter allows users to provide rich states to custom decoders. If you think this is an unnecessary overcomplication, I don't mind replacing it with default only.

What do you think?

[kitbellew]

@poslegm i like it, though need more time to read and understand. can you clarify: are you solving just the .add case for lists (or possibly maps), or will this also work for scalafmt's presets?

[poslegm]

can you clarify: are you solving just the .add case for lists (or possibly maps), or will this also work for scalafmt's presets?

My main task here is the .add support. I think that generic state propagation mechanic can help with delivering external input data (like presets) to custom decoders. But I don't play with it yet and I can't guarantee that.

[kitbellew]

@olafurpg this change looks good to me, and consistent with your comments to #90. can you please take a look, too?

[olafurpg]

If there is no rush on your end to get this functionality merged, would it be OK if you give me some time to try and draft an alternative solution that avoids breaking changes and also unblocks other use-cases besides defaults?

I'm not convinced it's the best way forward to use the design in this PR. I would love to have a solution that is more general that doesn't require the same advanced implicit machinery.

[poslegm]

Yes, of course!

[kitbellew]

If there is no rush on your end to get this functionality merged, would it be OK if you give me some time to try and draft an alternative solution that avoids breaking changes and also unblocks other use-cases besides defaults?

I'm not convinced it's the best way forward to use the design in this PR. I would love to have a solution that is more general that doesn't require the same advanced implicit machinery.

@olafurpg are you still thinking about an alternative? i saw a comment about your focus in moped now. any recommendation what we should do to support the functionality that @poslegm originally wanted to implement?