meander 2021-08-31 | Slack Archive

Looks like we got a tip on eliminating that warning.

Something I'd be interested in is a (m/case) where I solemnly swear there's no overlap & I don't care about order. I have a (m/match) like:

(m/match
  {::anom/category ::anom/unavailable} {:status 503}
  {::anom/category ::anom/interrupted} {:status 500
                                        :retry? true})

Which then generates one big fast case statement. However, if I switch each statement to an m/or

(m/or {::anom/category ::anom/unavailable}
      {:exoscale.ex/type :exoscale.ex/unavailable}) {:status 503}

because m/match preserves order, it degrades to (essentially) a cond check (kinda, it uses case with default causes to fall back onto other keys). I haven't benched the performance, but I'm assuming it's slower than a pair of case statements.

dominicm21:08:33

For now, I'll probably copy/paste as my then is pretty small.

2021-08-31

Channels