Closer to the source, I guess clojure.core/load and clojure.lang.RT/getResource are closer to it for Clojure/Java, and that is perhaps completely defined by the classloader being used.

@andy.fingerhut When I watched that talk, I took it to mean that you can choose to organize your code any way you want but what's important is what the REPL sees, essentially -- i.e., the forms that are presented to it in a specific order. All the file structure and name mapping is just convention.

I agree that you can get all your code loaded via a REPL without touching the file system for Clojure source files, if you define all the namespaces in the correct order as he mentions.

Maybe I am misinterpreting what he said, but I took it to mean that the mapping of say namespace foo.bar to a file named foo/bar.clj (in an appropriate directory) was unnecessary convention.

Insofar as dealing with the REPL, yeah, it is unnecessary -- you open the file in your editor, you evaluate it into the REPL. The REPL doesn't care where that code is on the filesystem.

If you're working like that, you don't need to follow any conventions for files / folders if you always evaluate forms into the REPL in the bottom-up order because you'd never cause the REPL to try to load namespaces that aren't already in memory.

I mean, almost no one is really going to try that... since all sorts of tooling is going to get horribly confused if you don't "follow convention"... and you'd have to make sure you loaded all the code in the right order every time so it would be painful... but, as he said, you could just stick everything in one file and just load that into the REPL.

It just seems to me that part of the tooling that will get horribly confused, and/or fail, will be Clojure itself, even in the absence of lein/boot/etc.

OK, yeah, in the context of his preceding sentences, it makes sense if the meaning is: "You can get by without a file system for source code in Clojure, if you really want to. It is optional." As soon as you do want to use files for Clojure source code, that is when namespace to file name mappings rear their head.

eh, there's load-file

but that only works when you are pushing code to clojure, not when clojure goes out looking for it via require and friends

and when @seancorfield mentions the editor sending code, that's likely either load-file or load-string

I stand corrected :

s/ 😕

Too much switching between Skype and Slack

(I'm not actually sure what ProtoREPL uses but with CIDER it would be some nREPL chatter back and forth -- the point was mostly that you can "send code" without the REPL needing to look at the file system)

Changing the subject... I was pleasantly surprised to discover that I can start a REPL in a Contrib project using clj and -Sdeps to specify the library as a local dependency

clj -Sdeps '{:paths ["src/main/clojure"] :deps {org.clojure/java.jdbc {:local/root "."}}}'

It reads the pom.xml file for dependencies. Very nice!

@noisesmith Right, if your code isn’t organised according to the package structure, even load-file and load-string will only work if either they contain no requires, or those namespaces have already been required (and I don’t see how the second could have happened if the code isn’t organised as expected).

So sure, technically it’s true that you don’t have to arrange your code according to convention, but you’re going to be extremely limited - either you reimplement something like require yourself, or you only use single scripts and maintain the dependencies between them in your head.