Maybe this is super bad, but I stopped using private functions for that reason 🙀

You lose some readability then. It’s nice to see right there that it is not meant for outside consumption.

I separate by namespace with one “API” namespace

But it’s becomes a bit of namespace explosion

So not a panacea

But asking in this fantastic channel helped. @U04V15CAJ’s tip to call it with #'foo works perfectly. The function stays private and the linter is happy.

He’s the dude

I am using an impl sub-namespace and this was functions down there. I should slap an API namespace on them for the lols. 😃

It’s funny how Clojure puts such an emphasis on immutability, yet is crazy malleable.

I like both private fns and separation into private nses for clarity, even if the user can, in reality, reach in and grab whatever they want, and abuse it however they want 🙂

The data is immutable, the program is mutable. 😃

BTW, I think you can also use the #'foo type of reference to ensure that you get the newest version of a function during development. I’ve had a situation or two where a direct reference netted me the old version.

don’t recall the exact use case

Another tip, if you have a private def is to altermeta

;; Make it available for testing...
(alter-meta! #'sut/transformed-default-notifications dissoc :private)

haha

of course 🙂

Private? I don’t think so

if you don’t want your stuff to be public, don’t write it 😛

One use case is hot-reload in e.g. shadow-cljs. Remounting a dynamically updated change to a component won’t happen if you use the symbol.

Feels like we need a defimpl or ^:impl that produces suitable warnings as opposed to the hard line private functions. I am not totally against an impl namespace, but I feel that it is basically trying to fix things using the file system which just seems more like a hack. The good thing about private functions is that related code can live nearby and you lose this by putting things in an impl ns.

just my €0.02

Other conventions include ^:no-doc and ^:skip-wiki

or just "implementation detail" in the docstring, also starting the function name with a dash is sometimes used: -foo-bar

I've done exactly as @U051F5T93 for a few years now in clj and I think my life has only gotten better :) I particularly like that skimming an "api" ns only has the relevant bits. I can jump-to-def for impl details if/when needed. Which is a pretty different experience from encountering a monolithic ns with api / impl details intermingled. Especially if I didn't author that ns - often I'll wonder "how do I read this", "where are the relevant bits", etc

Just checking. Having an api namespace and having an impl sub namespace is roughly the same thing, right? Else I am missing something. I have a project where we use #polylith and its insistence on interface namespaces is pretty nice and also sounds similar to what you describe, @U45T93RA6.

> Having an `api` namespace and having an `impl` sub namespace is roughly the same thing, right? Yes. I actually try do both at the same time: have foo.api + foo.impl, with no naked foo. This way consumers can realise which one is the intended api, which perhaps foo or foo.core would not convey > I have a project where we use #polylith and its insistence on `interface` namespaces is pretty nice and also sounds similar to what you describe I also use Poly at work. Indeed it seems similar. It might be a slightly more coarse-grained building block: one pattern is only concerned with namespaces, while the other involves creating a deps.edn file, etc. I have codebases with say 20 impl.clj namespaces, if I were to add 20 deps.edn files, directory structures, etc I would give up 😇

I disagree with that, private functions are often tasty, pure functions that are extremely simple to test. A deftest for them will look like a mapping of inputs to outputs. There's no possible brittleness in such a deftest. If it stops being useful you can just discard it. Brittleness comes from Java/Ruby-like patterns e.g. spies, mocks, etc; they're very literally complex because they tangle different defns, state, etc.

We seem to have a different perspective on brittleness. I am interested in testing the API of a namespace and not the implementation details. But this is software, so people are free to talk what ever approach they wish

Brittleness means “easily breaks”, right? 😃 Which I don’t think goes for tests of pure functions.

In any case. I am pretty sure I want the unit tests that led to the thread start here.

Is it pronounced “TEGIFF” or “TEJIFF”?

yes

I’m starting to suspect you are not randomizing these. 😀

the joy of randomness 🙂

This could include consultants etc.

What's up?

we seem to have created a bit of a mess in this respect... but have no clue what the best practices are.

and I certainly don't understand it all, how all these things relate to each other (IAM/Orgs).

Ping me