For the sake of expediency, I am simply eliding all hyperbole, which simply has no place in any professional environment, let alone a cross-industry specification body. If we could avoid that going forward it would be a great help to our productivity as a whole. I'm also skipping over off-topic discussion which can certainly be raised in another thread.
But the restrictions do come from the fact that we have to deal with String/String as least common denominator. Simply because there are ton of Config Sources around which are still only flat:
You are correct in a sense. We do, in the end, have to cope with flat structures at some level. This is not in any way disputed by anyone as far as I can tell.
But also in Thomas' proposal it will *internally* (in the ConfigSources) will be interpreted as the later: FLAT as String/String. Plus you right now need to write an explicit converter for each Pojo.
It it really would be TREE, then also the ConfigSources would reflect this!
I believe the original proposal suggested both natively-flat and natively-tree structured configuration sources. The flat sources would be converted using a consistent and common set of rules.
What also was not yet answered: if I navigate to a sub config node, how does it behave? When do the values get resolved? Is this resolved subnode mutable or immutable?
If it is immutable, then how do I get changes in values, or does it not support mutability at all?
This remains to be decided, but it is not an intractable problem. As discussed, mutability is a future topic. It is disingenuous to presume that it is unsolvable just because the proposed specification is different than the implementation you are familiar with (and before we repeat this again, please do not bother to explain how well tested or well used your implementation is; I think I speak for everyone when I say that we understand your position on this matter, and we all have our own implementations and knowledge besides, which is in fact why we are here).
So basically both solutions suffer / have to deal with the same problems.
I believe that this is correct, these questions have to be answered regardless. Part of the reason however that we've pushed the mutability discussion out a little bit is that I do not believe for a moment that we all agree on what use cases are valid or should be directly supported or indirectly allowed by the specification. This will be sorted out in a subsequent discussion, assuming we resolve this one in a timely manner.
