This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-04
Channels
- # adventofcode (161)
- # asami (2)
- # babashka (56)
- # beginners (128)
- # calva (57)
- # cider (10)
- # circleci (1)
- # clj-kondo (4)
- # clojure (13)
- # clojure-europe (44)
- # clojure-france (32)
- # clojure-italy (3)
- # clojure-nl (18)
- # clojure-spec (7)
- # clojure-uk (26)
- # clojurescript (18)
- # code-reviews (15)
- # community-development (7)
- # conjure (5)
- # cryogen (8)
- # cursive (31)
- # datomic (18)
- # emacs (8)
- # events (4)
- # figwheel-main (7)
- # fulcro (42)
- # juxt (3)
- # kaocha (58)
- # lambdaisland (1)
- # malli (1)
- # minimallist (1)
- # pathom (11)
- # pedestal (9)
- # re-frame (28)
- # reagent (20)
- # reclojure (4)
- # releases (1)
- # reveal (23)
- # schema (2)
- # shadow-cljs (7)
- # test-check (67)
- # xtdb (23)
I have a question regarding naming conventions:
I have functions which take a function as argument, (defn foo [f] ,,,)
, and I want to provide a macro which wraps a body as a function for this call, i.e.
(defmacro bar [& body] `(foo (fn* [] ~@body)))
I want to expose both foo and bar and give them names which are semantically close, i.e. foo-call, do-foo, foo, something like that.
Any suggestions? I started with an asterisk suffix but it seems ugly in a public api.Metabase uses foo
for the macro and do-foo
for the function that does the heavy lifting.
Thanks @UJY23QLS1, just to clarify my situation a bit, the functions in this case don't do code transformations (as in core.async/do-alt), but they do perform the work. Why do-foo
for the function and not the macro?
What do you think about foo-call
for the function (as in core/future-call)?
“Asterisk suffix for the version that takes a function” seems to be a common convention when it’s expected that the macro version will be the usual invocation method, and the asterisk version rarely used directly
I personally don’t mind the aesthetics FWIW
> Why do-foo
for the function and not the macro?
It's because foo
is public interface, so it gets the "prettier" (more idiomatic) name. The do-
prefix is just a convention. I don't know if it has other history (maybe it's a lisp thing?), but consistency is good 🙂
I'm also trying to be consistent with core.async semantics. I'll elaborate a bit Currently, what I have is https://github.com/bsless/more.async/blob/master/src/main/clojure/clojure/more/async.clj#L24: a process which repeatedly invokes a function and puts its results on a channel. I also have the equivalent consumer process. I want to mimic core.async semantics of async! and blocking!! suffixes, and I also want to support a macro version which packs an expression into a function so my options are things like (function/macro) • produce!* / produce! • do-produce! / produce! • produce! / do-produce! I really can't figure out which is more idiomatic. I also want both macro and function version to be public. Naming things is hard
> Naming things is hard
☝️ This.
If you want to make both function and macro public, I usually try and think about what would make sense when I read it being used. To that end, what about produce-with!
/`produce!`?
And for public vars I'd avoid suffixes like *
. Rather add a descriptive/distinguishing word.
That's why I thought about do-produce for the macro version, because it takes a body, which is a very do-y kind of thing
My general solution is to search for conventions in core, then in core libs, then I start making shit up
Isn't this the same thing that future does? future is a macro that internally calls the func future-call, in core.clj