ConfigImpl doesn't respect key order about config

[havocp]

one question is what happens in a merge (withFallback). what if one file has order a,b,c and we merge with one containing c,b,a ...

one solution for your case might be tasks=[ process.args=,cleanup.args=]
since lists are ordered ?

[esuomi]

Yes, using a list could also possibly work, although then there's some additional boilerplate needed to get to the actual values.

In merging I think the withFallback should be properly structured and entirely separated from the main configuration key-value pairs Map. In other words, the keys should form a strongly typed hierarchy instead of everything being in just one flat map. Usage wise this is comparable to include being an inlining operation, where contents of another file are inserted to the position where the include directive is.

[havocp]

Coming back to this much later with more time to think about it...

I guess we'd want withFallback to work the same way with respect to order as this (imagine cutting this in half at any line, and the second half is combined with the first using withFallback):

a=1
b=2
a=3
c=4
a=5

So the question is, where does a end up in the final order. If the first half is a b a c then do we collapse that to LinkedHashMap with a b c or b a c after combining the two a? And then when we do second.withFallback(first), if second is just a and we merge it back with b a c, is the result b a c or a b c? What if we split into three pieces and then merge those?

We would have to define this such that withFallback continues to be an associative operation, which is an important assumption in the library, but I think that isn't actually possible unless order is NOT considered in config object equality. But if order is meaningful, it really should be part of equality.

Another angle to think about this is, what if reference.conf has keys in order a b c and application.conf has c a but doesn't specify b. So what do we do here; do c and a swap and leave b between them, or do c a both move after b, or what. I don't see any principled answer, or anything that would be intuitive.

Perhaps to solve the problem here we could introduce a separate "ordered object" type and basically that object type would not allow merges, only replacement. But this would be quite a lot of conceptual overhead and code. I think it's probably better to just use a list.

I'm closing the issue for now since I don't see a path forward but don't let that deter others from trying to think of one. Just think about the withFallback problem, where we generally assume that we can concat two files and that is equal to file1.withFallback(file2), and we also have to cope with multiple instances of a key within a single file...