Hi Anatole! Thanks for your productive response, anwers inline:
> Am 20.07.2016 um 17:00 schrieb Anatole Tresch <[email protected]>: > > Dont get me wrong: I completely agree we need an SPI, so we can hook in;) > > Basically we need: > 1) a function for access of Configuration: *f() -> Configuration * > -> this can be implemented by *ConfigurationProvider.getConfiguration()*; +1 Some kind of factory. As proposed. > 4) For adding up functionality/implementing interfaces not known by the API > we can easily add up an independent component and leverage the GoF Adapter > pattern, realizing a function *f(Configuration) -> x*, x being anything > that may make sense. In code this could look like something > TypedConfiguration config = AdapterManager > .adapt(configuration, TypedConfiguration.class); Sounds a bit too complicated and I fear that a too ‚generic‘ approach will not be practicable. > 5) Another point is that if we minimize *Configuration* IMO the concept of > *PropertySource* makes no sense anymore, Fine IF we manage to get an easier SPI which is at least as flexible as the ConfigSource mechanism. Remember we started with 100++ classes for such an interface. With the ConfigSource approach this can be made as little as 2 interfaces (ConfigSource + ConfigSourceProvider) > because it is duplicating the same > abstraction/functionality already defined in *Configuration: supplying > key/value pairs*. No, Configuration is the result of n ‚merged‘ ConfigSources. But they are not the same. That’s like saying a balance sheet only consists of the final summary numbers. Of course that’s the most important thing from a managers POV. But how did those numbers got there? > > Just to give some ideas. I really believe we dont need much fancy things, > just combine what is already out there. IMO some generic aspects should be > considered and we are done. +1, see proposed approach. Of course it doesn’t need to be 1:1 what I coded. My proposal is just to showcase that a possible API could be implemented way more precise (and thus smaller) as what Tamaya has right now. If you have something better, then show it (plz via patch or on github, as we cannot get rid of any experimental commits from our GIT repos as explained before). LieGrue, strub
