Fork me on GitHub
#beginners
<
2021-04-10
>
Michael Lan02:04:37

Cant quite find what the recommended solution to this is on the interwebs:

solf02:04:14

To not use :refer :all. Instead, use an alias:

[cheshire.core :as :ch]

...

(ch/parse-string ...)
Or manually refer to the functions you use:
[cheshire.core :refer [parse-string]]

Michael Lan02:04:53

Oh, so that message is basically telling me doing :refer :all is a bad practice 😅

solf02:04:04

This is to avoid polluting your namespace by referring to all kind of functions that you never use. It’s the same reason why :use is not recommended, and to easily know where a function comes from

👍 6
seancorfield02:04:19

@U01ML6ZL2U8 as a good rule of thumb "always use :as with an alias", and it's common to use the last unique segment in the namespace as the alias -- but sometimes a shorter, obvious mnemonic is more readable (:require [cheshire.core :as json]) is something you'll see a lot. In the same way that the most common alias for clojure.string is str.

seancorfield03:04:22

There are a few things that are okay to :refer in, because it makes the code more readable than using an alias. For example, with clojure.test, it's fine to :refer [deftest is testing] -- and if you look at clojure.core.async code, you'll see folks will typically alias it as async but also :refer in the operators (`<!`, >!, <!!, >!!).

seancorfield03:04:56

(In tests, I tend to alias the namespace being tested as sut -- system under test -- but that's not very common in the Clojure world I don't think)

3
dharrigan07:04:23

I use sut too 🙂

seancorfield07:04:13

I wonder if it’s more popular in the UK than the USA?

dharrigan07:04:52

Perhaps we can ask to put it on the next State of Clojure survey 😉

Richie14:04:17

Hey! clojure spec docs say that cat matches a map… https://clojure.org/guides/spec > Conforms to map with named keys based on the `cat` tags

(s/explain (s/cat :x int? :y int?) {:x 2 :y 1})
{:x 2, :y 1} - failed: (or (nil? %) (sequential? %))

Richie14:04:36

Why doesn’t this work?

Richie14:04:22

The issue that brought me to this was in trying to match a nested vector.

(s/explain (s/cat :a string? :nested (s/cat :b string? :b string?)) ["a" ["b" "c"]])
gives me
["b" "c"] - failed: string? in: [1] at: [:nested :b]

Richie14:04:08

I guess they’re two distinct questions.

alexmiller15:04:27

It conforms (outputs) a map

alexmiller15:04:51

cat always matches a sequential coll

alexmiller15:04:54

regex ops combine to match a single sequential coll. If you want to match nested colls, wrap the inner one in s/spec

Richie15:04:43

Ah right! Sorry. There’s enough new stuff that I’m already forgetting things. Thanks!

Richie19:04:15

(require '[clojure.spec.alpha :as s])

(require '[clojure.spec.test.alpha :as stest])

(defn fun [i]
  (inc i))

(s/fdef fun
  :args int?)

(stest/instrument `fun)

(fun 8)
(8) - failed: int?
Sorry to be back again so soon. I’m pasting this code into a 1.10.2 clojure repl and I’m getting an error so I don’t think it’s anything with my environment or my other code. I don’t expect an error here, what gives? Thanks in advance!

dpsutton19:04:57

check out (doc s/fdef). The error is how you are specifying the :args spec

dpsutton19:04:22

think about how you would have to spec fun if it had two args, and how that would structurally change the :args spec

dpsutton19:04:21

i'll post the "solution" in a thread but it's worth thinking for a second

dpsutton19:04:31

(s/fdef fun
  :args (s/cat :i int?))

dpsutton19:04:33

consider if fun took two arguments. there would be no way to add the second argument's spec to :args without changing the cardinality from 1 to many. The answer is that the args is always a sequence of specs, and in this case it has only one spec

dpsutton19:04:42

also, notice the error message doesn't say 8 failed: int? but (8) failed: int?.

Richie19:04:59

Oh! I was wondering why it was in parens. I only get it now that I’m thinking about it being in a list.

Richie19:04:27

That was really bothering me, thank you so much for pointing that out.

Richie19:04:33

I’ll need to use s/cat then. Aww man, I totally missed that. Thanks for pointing that out. Yea, it’ll help me to remember to do that if I consider how it would scale to more arguments like you said.

👍 3
piyer20:04:48

I am trying to find a blog post on core.async anti-pattern, any recommendations?