Fork me on GitHub

whats canonical when you have defmethods spread across several files if I require the defmulti, but not the defmethods, the multimethod won't be implemented correctly (?) so I created a file all.clj that requires all the other namespaces with defmethods, is there a canonical pattern here


The only other options to requiring them all is require either some or none of them. 🙂


But in my experience I mostly see people in this situation requiring them all in whatever their “root” namespace is.


is there a programatic way to crawl the root namespace


and require it all


one elegant construct is that the ns that defines the defmethod also defines the data that you want the method to handle, but that's not always how defmulti / defmethod are used of course


namespaces don't have a tree structure


hm okay file-seq seems too much of a hack to me


when you package into a jar, you can't use file-seq as it's all in an archive


If I’m being totally honest I think this is a smell.


one option would be to scan for clj files available via classpath whose full path matches some pattern...


if I go down this route, i'd query clojures namespace meta data


but it doesn't seem very canonical


I might take moment to rethink the design.


that doesn't tell you about clojure files that haven't been required


and if they have been required, the multimethod is there :D


I can picture an idiom of saying "all clj files with in path will be loaded because it is assumed they provide implementations of the bar multimethod"


I'm not sure if that's the best solution, but it can be done, by scanning for classpath resources via a regex


Or you can just do the simplest thing and maintain a namespace.


yah i'm going to stick with that


clojure.core/load exists, it finds a resource and loads it


the reason to do the resource scanning is if you are effectively doing a plugin system - promising to load third-party extensions if available


but agreed, just requiring the files is a lot simpler


most code I've seen that defines a multimethod defines a bunch of methods in the same file immediately afterward - just because it operates on a different kind of input doesn't mean it needs its own file


Yah, I tend to stick with keeping the method definitions in the same file too because spreading them across files is a little bit like spreading mutable state around. Not saying its bad or anything but it does have implications.


the correct structure is a diamond


defmulti/defprotocol in a ns(spi), that namespace required by every namespace with an implementation of that multimethod/protocol, then a namespace(interface) that requires the defining namespace, and the implementations, and invokes the multimethod or protocol, doing any argument massaging, etc, as needed


that is when you have this stuff all in the same project, of course protocols and multimethods are an open set


I would s/the correct/a because a line would be fine too.

defmethod -> impl -> api


And agree diamond is nice too. 🙂


the diamond is clear, easy to understand, easy to use, and has no footguns


tell your friends


(it is kind of less of a thing with protocols for various reasons)


I think a strait line has the same properties and advantages, I haven’t been in a situation of my own design where a diamond would have provided more benefit.


At the same time though, over the years I’ve gotten more conservative with how I use multimethods/protocols.


@U0NCTKEV8 do you have any resources that discuss the relevance of the diamond in connection to open sets? Diamonds come up in other spaces (Chuch-Rosser) so I’m interested.


@U0J3J79FE For a big project I have several multimethods spread over a dozen of files. I use seperate files to keep it manageable in my mind (and for my editors). I have a main ns that requires all implementation namespaces and a protocol namespace [where (defmulti ...) lives]. I have all the requires in main at the top, but actually I have forgotten to add requires and I would re-eavaluate and that extension wouldn't be picked up. Definitely annoying. I can imagine a helper macro (require-* ) that requires all namespaces in a subdir can be of use here. Depending on the type of project this could or could not be a code smell :)

Wes Hall20:02:22

Hopefully this is more diagonal than orthogonal but I think trying to drop the habit of having many small namespaces is a good path out of this kind of problem. You don't need to put everything in the same namespace, but if you are finding yourself in a situation where there is a namespace that you need to require for the sole reason that it has a defmethod you need then it might be a sign you are going a little too fine-grained. It's subjective of course, but I personally find namespaces that include some general architectural concept (impl, spi, protocols, etc), a bit of a smell in themselves. You quickly run into the "2 dimensional" problem. Do you want .users.spi or .spi.users or just .spi and .users and then agonise over what goes where? clojure.core is pretty big and it's fine.


I don't think there is a right or wrong here. This is also not a thing of habit, It's a moment where one approach feels better than the other. For the record, after splitting up the namespaces these namespaces are still big. It might be a matter of taste or maybe I have less brain capacity or editor skills :) I like the fact that protocols and multimethods give you another way to organize your code. Even clojure.core is defined in multiple files e.g. or . Using multiple files also helps during reviews as it is easier to see what parts of your application are being touched.

✔️ 8
Wes Hall23:02:29

@U0FT7SRLP All entirely fair. There are some practical reasons why you might want to split up your code into some smaller namespaces, you list some of them here, but I think there are also reasons why you might consider merging them. One of them being problems like the OP has, or having circular dependency issues. I do think, for people who come from, say, a Java background (as I did), where classes are the most fine grained level of "namespace", and the file division, there can be a tendency to perceive clojure namespaces as being "like classes". The clojure approach to requiring vs Java imports and things like :gen-class can serve to support this idea. Having some of clojure.core spread across different files also serves to demonstrate that this is an option available to us if we need it. The primary clojure.core file is still pretty big though. When I have had problems like the OP in the past, I have often started to merge some of my namespaces, solved the problem and been OK with the result. Often the result has felt better since I suddenly find I am not sitting with 4 or 5 emacs buffers open while trying to work on a single feature. It's hard to give concreate advice without the full context, but I just wanted to throw it out there as an option worth considering.


Thanks for explaining. I agree with all the different views here (all depends on the context indeed)

Chris Lester03:02:01

Has anyone had problems using specs as generative tests, where spec's stest/check cannot generate (gives up) but s/exercise and s/exercise have no problems with the respective parameter specs and fn spec? Also tried stest/check-fn after reading the source for stest/check, but it is complaining about the result not being a map ... and since no one ever seems to have used that assume I'm using it incorrectly.


@activeghost That can happen, yes. Generative testing pushes the generators a lot further than exercise so you get bigger / crazier values going through the specs.


If you run (s/exercise ::the-spec 100) or maybe 1000 you may well get the "such-that" error.

Chris Lester04:02:02

Yep, that's what is going on -- so some grovelling over huge amounts of data is needed ... or is there a means to limit it (looks like I'd have to override the generator?)?


There's no easy way. You have to exercise each component spec from the bottom up to figure out at what point the constraints are too tight for the built in generators...


...or if you have s/and constraints, you might start there.

Chris Lester04:02:47

That's what I was afraid of .. which I've done to get to this point lol .. .but not enough apparently.


The such that failure is generally at a point where two constraints/specs are combined -- and then you have to add a custom generator somewhere, or rethink the constraints.


I just went through exactly this problem about two weeks ago.

Chris Lester04:02:19

I have several custom generators, and a bunch of s/and specs. Will go back through them starting at the leafs again with the size set to 100 then 1000.


I was adding specs to a big piece of legacy code that I didn't write and it took me... three or four days I think? I finally got to a point where everything worked and I learned a huge amount about that code and exactly what its data structures really were.

Chris Lester04:02:02

Nice. I'm specing this for a legacy monolith (these maps are cable channels essentially) and as a materialized view for clients while they move to a new data model. It does teach you a lot about the system.


This was a big data processing pipeline that took a bunch of metadata in, transformed it based on what's in a database, then used that new metadata to drive queries against a bunch of database tables, and then transformed that into data suitable to drive a bunch of graphs being displayed.


I did actually find a couple of bugs in it while I was spec'ing it all -- bugs we'd never noticed while using the system for maybe five years? -- and then I was able to refactor it to make it easier to test some new processes we were building on top of the graphing engine.

Chris Lester04:02:37

That sounds like a fun project, haven't done any graph ux work outside of R.

Chris Lester04:02:34

Found the problem, and there was only one 🙂 ... apparently it can't go beyond 50 with the collection in the snippet, even though the underlying specs generate at 100 (but not at 1000). However switching to what I should have used - pos-int?, fixed that problem for the entire map and stest/check now passes. ... Thx!


@activeghost Oh cool! Glad you found it. Yeah, learning all of the available predicates that generate is a big job.


One thing I seem to do fairly often is to optionally run a function on a value based on the result of a predicate of the same value, and otherwise return the original value unmodified. Is there a nice way to do this, without having to repeat the value? Expressed as an if, this is an example of logic I want

(if (string? x)
  (read-string x)
I can avoid repeating x once with cond-> , but basically I want a version of cond-> that also threads the value through the predicate. I can write that, but maybe there's another way to do it in clojure.core?
(cond-> x
  (string? x) read-string)


Had similar thoughts before. I don't think there's another way to do it with the built-in constructs. But it's a fairly simple macro if you want to implement one.


I say leave it the if expression. There's nothing wrong with it. Totally clear. Unmagical.

👍 4

but if you do want to obfuscate it I can think of two ways


(-> x string?
    (and (read-string x))
    (or x))

😱 8
😂 4

(defmulti processor type)
(defmethod processor String [x] (read-string x))
(defmethod processor :default [x] x)
(processor my-x)

👍 4

also... nothing wrong with putting a simple if like that on a single line, I say


I think cond-> is perfect among all other built-ins. As terse as possible, without losing any legibility.


There's also the condp-> macro from

👍 4

Thank you for your thoughts! I hadn't made the connection with defmulti, that was interesting, though obviously too verbose for the simple case. Also thank you for the mentioning of condp-> which is indeed what I was thinking about although not in core. At least it shows I'm not the only one thinking about it.


Maybe a simpler function would be better, like (modify-if val pred fn & args), then you'd be able to use it with thread macros

👍 4

Thanks for mentioning our library from work (`condp->` etc).


If I were to re-publish an article about the state of Clojure with a Java magazine, that has to be updated from 2015 -> 2020, what would be good to add, focus on? spec, deps.edn, ..? Feel free to respond in a thread.


I think one thing to add is the stability of the language (which was already true, but still is)


Clojure: Now with error messages

💯 4

+9000 for Stability! Spec, tools.deps, the graal story, datafy, nav are all valuable to mention IMHO. We'd have much more to say about spec though, once it comes out of alpha, where the new syntax for fn specs, the schema-select stuff and programmatic spec manipulation will make it that much more valuable. We'll have more to talk about interop when 1.11 lands because of the integration with new functional APIs of Java that Alex Miller was hinting at.


slower start-up times


@U04V15CAJ Did the 2015 article cover 1.7 with transducers? (just figuring out what part of the history is "recent" compared to the article)


yeah, it did


not that we explicitly mentioned them, but we covered that point in time let's say


OK, so direct linking (performance), socket server/repl, Spec, CLI/`deps.edn`, Java 8 as a minimum (1.10), datafy/nav, tap, error messages.

💯 4

It's really interesting to read through and see just how many tickets get addressed in each release but how sparse the "new features" tend to be -- but how impactful they often are.


will you mention rebl?


Ooh, yeah, a +1 for REBL!

Guillermo Ithier21:02:48

Hello all, I'm currently working on building micro-services for a client on a real-time application and would like to know if anyone is interested in working with me at a part-time bases. My services will be communicating with a MONGO database and the front end of the app will be in React. There is compensation for this project so if you are interested I would prefer to workout the logistics in private. Thank you


Just FYI, there's also #remote-jobs

Guillermo Ithier22:02:40

Thank you 😊 I'll give that a try; new to Slack