What's the use case?

Bridging :) without bothering users about implementation details, allowing to write loaders simpply and focus on business value;

class MyBaseLoaderextends ConfigurableArrayLoader {protected$target;publicfunction__construct(Domain$target) {parent::__construct(newBusinessConfiguration());$this->target =$target;    }}class MySpecialJsonLoaderextends MyBaseLoader {publicfunctionload($file) {returnparent::load(json_decode(file_get_contents($file));    }protectedfunctionloadConfiguration(array$config) {$this->target->setBusiness($config['business']);    }}

But users don't write loaders, that's not a business responsibility...

True, but it depends how the user relies onSF\Config, it may not be using DI loaders etc.

Anyway, ill have no strong use case myself now. Just trying to make lib code more robust and easier to understand/implement.

Adding more code is not going to make it easier to understand IMHO...

Agree, not per see. Just saying (from a component pov) i could appreciate having this kind of self-bridging classes, doing things once; exposing patterns; exposing business value.

I agree with@nicolas-grekas. We never add a feature without a real-world use case. So, I'm closing this PR for now.