Fork me on GitHub
#clojured
<
2021-07-13
>
pithyless09:07:58

Just watched @lorilynjmiller's talk on :clojureD and there's just one thing that bugs me in the implementation of map-current-view [0]. The use of (atom {}) and some creates an implicit assumption of order and priority (more than one predicate may be true, but choose the "first"). I see 3 ways I would try to fix this assumption in my own code: 1. Change the atom from a map to e.g. a vector - and then you would have an explicit priority order (e.g. based on the order register-view! is called). Of course, you'd have to manually handle the logic of registering in the same key twice. 2. Use filter instead of some and then assert that you only have max one key (otherwise you can fail with some sensible info about multiple matching predicates). 3. Use filter instead of some but then also sort (e.g. by some optional priority key or other logic). But this is starting to smell like CSS !important I think I'd opt for #2, but I wonder how others would go about solving it. Or perhaps this is considered a non-issue. Either way, thanks for the talk and a fresh perspective @lorilynjmiller! :) [0] https://www.youtube.com/watch?v=kv-bHHHGeV4&amp;t=856s

lambduhhh16:07:46

🙂 Thanks @pithyless! So I can speak from my own experiences that I consider very heavily the implicit assumption of order in the conditions. This forces each condition to be specific and distinct and I think that can actually be a good thing as it enforces good descriptive data. Has that been the source of a bug caught by QA? haha yes. but it was very easy to debug/resolve since to troubleshoot I just referred to the data and went down each condition until I found the "double". When I did find the overlap I added in something to distinguish them from one another. Your suggested solutions sound like they could work too! I would also lean towards #2 though, as I'm not sure introducing the additional complexities of the other methods would necessarily be a good pay off.