s/conformer conversion loss in (very common) s/merge edge case
Description
Environment
1.9.0-alpha14
Activity
import October 4, 2016 at 3:08 PM
Comment made by: akahl
I just read again your comment Alex Miller and finally started to understand how (s/keys) conforms all namespaced keys, so please disregard my other comment.
I still wish there was a solution that worked for multiple maps of unqualified keys. Otherwise, I'd have to expect my users to use qualified keys throughout configuration files which looks a lot like redundancy, unless I convert all the keys first.
import October 4, 2016 at 2:50 PM
Comment made by: akahl
Oh geez, I meant 13 (and first observed in 12), wish I could actually travel back in time!
If what you're saying is right, why doesn't this work, as both (s/keys) use only unqualified keys?
Alex Miller October 4, 2016 at 2:36 PM
alpha14 isn't out yet, so thanks for traveling back in time to report this!
I think this is not a bug, just a subtlety in how merge conform works. Specifically, merge does not flow conformed results, you only get the conformed result of the last spec in the merge.
In this case:
the spec determining the conform value is (s/keys), which will conform all namespaced keys, including ::value.
In this case:
the spec determining the conform value is also (s/keys), but s/keys only conforms namespaced keys and there aren't any here, so you get the original map.
If you want the conformed value, you can swap the order in the merge because the first spec is conforming the unqualified key:
When using
s/conformon a spec generated bys/mergethat uses non-namespaced keys froms/keys, keys that use a customs/conformerlose their conversion.Steps to reproduce:
While this seems like an edge case, it is very likely to occur since using
s/mergewith unqualified keys is a typical use case for configuration files. I first spotted this behavior in alpha13 and it still occurs in alpha14.