Yeah, it supports a file system abstraction over other things as well, such as a ZIP file, for example. I use that in depstar

Well, I'm not too sure, but I'd assume there can be many filesystems in use, say you have a USB key plugged in for example, and your hard-drive, that would now be two accessible file systems

Hum, ya, that's where I'm not really sure of any details 😛

@deleted-user https://github.com/seancorfield/depstar/blob/master/src/hf/depstar/uberjar.clj#L332 -- that's where depstar opens a new FileSystem on a JAR (zip) file

and so if the library is being asked to join paths, for instance, you want to know the file system

Paths is one thing I was thinking

Like if a NTFS partition is mounted on linux

Though I'm guessing "mounting" would actually have the OS adapt the NTFS filesystem to the current one

@deleted-user dynamic variables are... problematic... start by assuming the filesystem will be passed into all your functions and provide an extra arity that calls each function with the default filesystem).

Where shall I start? 🙂

I don't have the time/patience tonight for it to be honest, sorry. Just don't do it 🙂

I'll be happy to explain when I'm back at work on Monday tho'...

I only know that you have to be careful not to depend on them in a context that runs after the binding is gone.

And thread boundaries

It's really problematic if a library uses a dynvar because then you can't have multiple instances in use and, yeah, the threading issues. And it makes testing harder.

And it's not considered idiomatic either.

Hum.. isn't the whole point of dynamic var is they enable multiple instances?

@didibus No, they break that use case.

I'm not following that I guess. Each caller has it's own binding established no?

For example, when I took over clojure.java.jdbc, it relied on a dynvar for the DB and that made it really hard to use in code that needed to talk to multiple databases because you end up being forced to call binding everywhere around every call to the library.

Ok, I see what you mean in that sense.

I normally use dynvars for cross-cutting concerns

Like injecting a specific logger or metric object

They're also better then global configs.

But Sean is right, that for options, having an options map might be better

Well, I'm not against them, and I do use them, like I said, for cross-cutting concerns.

As long as you are careful around lazy-seq and thread boundaries.

But I think what I got from Sean and his java.jdbc example, it is a usability thing for the library

Say I want the cwd to be set to x/y/z for a number of operations

Now I need to either do everything inside one (with-cwd ...) or I need to keep repeating (with-cwd x/y/z) over and over in many places

Where as it might be better to allow the user to do: (def options {:cwd "x/y/z"})

And then do whatever I want passing those along

You need to consider whether folks using your lib are likely to need multiple filesystems or not (in your case).

Ya, and if I really didn't want to repeat myself, I could partial all the functions or something like that too, if I don't like typing options on every call

But depstar is pretty simple and it already needs two filesystems.

It can depend if you're going for ultimate convenience or flexibility.

Taking an options map I think is a good middleground between the two.

Ya, that can make sense too. Probably easier to add bindings over API that take options already then the other way around

But, if you're imaging it being command line driven, I could see even going for a global context.

Well, I mean like, would you ever want two cwd at the same time? If not, the global context can be locked or using an atom under the hood for example

(change-cwd "x/y/x) could swap! some atom for example

Ah okay then

Dynvar or options map are similar-ish, but with dynvar you need to nest things to use the configured values, where with options you can have things flat and thus more easily reused in varying contexts. I'd say that's the biggest difference in terms of usability.

Do you know if babashka does binding conveyance ?

Like on future?

I tried, it seems it does

user=> (def ^:dynamic *a* 100)
#'user/*a*
user=> (binding [*a* 200] *a*)
200
user=> (binding [*a* 200] @(future *a*))
200

And this is an example of what to be aware with dynvar:

user=> @(binding [*a* 200] (delay *a*))
100

So that's something your users would need to be aware of as well

user=> (def ^:dynamic cwd "z/y/z")
#'user/cwd
user=> (defn read-file "A mock to demonstrate" [file] (str cwd))
#'user/read-file
user=> (binding [cwd "a/b/c"] (map read-file ["file1.txt" "file2.txt"]))
("z/y/z" "z/y/z")

This is probably the worst offender which will trip up people

well I'm making up here that read-file is from your library, but because I call it in a lazy seq and it is realized after the binding context has exited, it is using the wrong cwd

haha, ya, I mean again you'd know best how you anticipate your lib to be used and if these edge cases would be common issues faced by users or not

just laying down the edge cases I've faced in the past with dynvars

@didibus Yes, babashka supports binding conveyance

I have a list of symbols (def my-sym '[ a b]). These symbols have not been declared yet. In a function -

(defn abc
  [a b]
 my-sym)

with def you define a value

why do you expect it to behave like a function afterwards ? 🙂

or like a macro .. i'm not even sure what you have meant here

There is a list of symbols which I need to reuse in multiple places, I could have written the fn simply to return [a b], but then I would need to keep my multiple fns in sync

i think you are expecting def to behave like #define in C

like a templating tool ? 🙂 but that's not what it is ...

It is usually not a good idea to assume local var names when reusing code. But perhaps something like this would help remove redundancy?

(defn abc [& args]
  (vec args))

Macros can be used to do such things, but like I say it is not a good idea to assume local var names.

cant I make it work without macros, something like (eval (map symbol my-sym)) (which gives an error)

There may be some way to get eval to work for this. But the common practice is that macros and eval should be avoided unless a function really won't meet the need. I don't use eval at all.