This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-21
Channels
- # announcements (5)
- # babashka (81)
- # beginners (26)
- # calva (6)
- # cider (7)
- # clojure (26)
- # clojure-czech (1)
- # clojure-europe (19)
- # clojure-nl (4)
- # clojure-spec (5)
- # clojure-uk (21)
- # clojuredesign-podcast (2)
- # clojurescript (19)
- # conjure (6)
- # cursive (13)
- # datomic (2)
- # depstar (1)
- # editors (2)
- # graalvm (25)
- # honeysql (5)
- # jackdaw (4)
- # jobs (5)
- # lsp (8)
- # malli (13)
- # music (1)
- # polylith (3)
- # practicalli (1)
- # releases (1)
- # remote-jobs (2)
- # sci (10)
- # shadow-cljs (5)
- # sql (14)
- # tools-deps (25)
- # xtdb (65)
@emccue thanks again, i really like how the shape of this looks, you basically gave me the push i needed to throw out the contract abstraction web3j had entirely and it’s so much better now
i can just auto-select a method by the parameters you pass. there’s validation underneath so if you pass params that don’t make sense for any of the methods in the abi it just rejects it when you try to encode the calldata
when i’m actually done with it i’ll post it 🙂
basically what i’ve wanted is something that lets me hack around with this stuff in the same way that ethersjs does, but, you know, in a good language
Question/curiosity: what is the rationale for spec’s keys function to be like this: (s/keys :req [] :req-un)
? Why not using a map? (s/keys { :req [] :req-un []})
?
Doesn’t the first approach complicate the code a bit since they have to guess the parameter order and make sure it’s correct and stuff like that?
easy to parse either way via kwargs
actually in 1.11, you will be able to pass a trailing map to a kwarg-style function, so actually both should work with literally the same existing code
Doesn’t that pose the burden to validate the order of the arguments? For instance, you would need to spec the function to make sure you don’t do weird stuff such as (s/keys [] :req :req-un)
By using a map it would be way easier, or not?
no, that's already covered at calling by kwarg destructuring and in spec with s/keys*
they are both equally easy (and in 1.11, actually literally the same)
functions/macros defined like (defn foo [& {:keys [a b]}] ... )
can be invoked with (foo :a 1 :b 2)
in this special case, you can destructure the "rest" of the args (a sequence) as if it were a map
Ok that makes a lot more sense now, thanks @alexmiller
the new thing that has been added in 1.11.0-alpha1 is that you can also supply a trailing map for kwargs
…as in just throw a map as kwargs and it will automatically use it to supply the arguments?
so (foo {:a 1 :b 2})
will literally be treated the same as (foo :a 1 :b 2)
but also (foo :a 1 {:b 2})
for some of both
Cool. Thanks @alexmiller