This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-13
Channels
- # announcements (1)
- # babashka (29)
- # beginners (64)
- # calva (4)
- # cider (5)
- # cljs-dev (3)
- # cljsrn (2)
- # clojure (100)
- # clojure-australia (2)
- # clojure-conj (7)
- # clojure-dev (9)
- # clojure-europe (31)
- # clojure-germany (1)
- # clojure-nl (2)
- # clojure-uk (13)
- # clojured (2)
- # clojurescript (62)
- # community-development (2)
- # conjure (1)
- # cursive (21)
- # datomic (39)
- # events (2)
- # fulcro (7)
- # graalvm (24)
- # graalvm-mobile (11)
- # holy-lambda (3)
- # jobs (7)
- # lsp (15)
- # malli (26)
- # music (1)
- # nyc (2)
- # off-topic (18)
- # reagent (23)
- # reitit (5)
- # remote-jobs (1)
- # shadow-cljs (2)
- # tools-deps (26)
- # vim (6)
- # xtdb (17)
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&t=856s
🙂 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.