Closed vemv closed 4 months ago
ps - I know that ring.swagger.schema belongs to a different project (of yours), but I thought it'd be nice to create just 1 issue instead of 2, and in the repo that tends to be used more often.
I couldn't agree more with the reporter :+1:
Library Version(s)
Latest
Problem
Potemkin's
import-vars
isn't a great mechanism. One can find argumentation for that from very reputed sources in https://groups.google.com/g/clojure/c/Ng_GXYSrKmI/m/q0cxahB3BAAJ - it's worth a read :)In practice, the problems I have with APIs that are potemkin-based are:
:refer
ed can confuse tools.namespace:...which forces one to
(t.n.r/clear)
, which is a productivity hit.I'd say that
import-vars
seemed a great idea at the time, but as the years passed it became more evident (and widely known) that it isn't.May I suggest, please consider sunsetting the Potemkin-centric API. For the
compojure.api.sweet
ns, I can easily work around that (by performing the underlying requires myself), although there's the social problem that you keep fostering something broken, which can easily make newcomers lose their time to Potemkin intricacies.For the
ring.swagger.schema
ns, there's the problem that it mixesimport-vars
with a few vars of its own (e.g.#'coerce!
), so I cannot use said vars without Potemkinizing my env.Thanks - V