Yup

you can close over state when you construct a function or reify an interface

like this?

(defn f1 [a b c d] ...)
(defn f2 [a b c d e] ...)

(defn make-client [a b c]
  {:f1 (partial f1 a b c)
   :f2 (partial f2 a b c)})

that's just a naive guess - would something like that be idiomatic?

Ok, sorry, said yup and got distracted

A common pattern is to do this:

(defn make-client [option1 opt2 opt3 ...]
  {:option1 option1
   :option2 opt2
   ...})

(defn get-items [client-map some-other-arg ...]
  ...)

So say you had the Java class:

public class Client {
  private int x;
  private int y;

  public Client(int x, int y) {
    this.x = x;
    this.y = y;
  }

  public method1() {...}
  public method2() {...}
}

the "client" here is just a hash-map that groups the common args, looks like

Ya

It is

So the above class would become:

(defn make-client [x y]
  {:x x
   :y y})

(defn method1 [client] ...)
(defn method2 [client] ...)

that's too simple

😉

i love it. thank you!

And the difference will be that, the map is immutable. So your defns are not really methods anymore, because methods are assumed to mutate the fields. In our case, if you only need to read from the fields, you just read what you need from the map. But if you need to modify the fields, you would instead return a new map which is the given client map with whatever changes applied to it.

i feel like another important difference is that we've mostly eliminated the abstraction that is a stateful "client"

the fact that it's still called a 'client' notwithstanding

Ya, it depends. If the things in your client map allow you to make a remote call to a mutable database, there's still some state in that sense, but it's moved away from your "client" object, and is now where it should be, in your DB for example

And what's nice with this, is you can now call it like so:

(-> (make-client 10 20) (method1) (method2))

Given in this case your methods were to return back a client-map as well.

Which is often the case. Like everything that would be void in java, in Clojure would instead return the client-map

So you get fluent interfaces for free

And if you want to group the client and all its methods into one logical place, then just create a namespace for them and shove it all there 😛

This pattern can extend quite far, if you ever need some polymorphism, you can make the map a record, and put the functions inside a protocol. Or keep it a map, but modify some of the methods into multi-methods, etc. Lots of options for handling all possible scenarios

If people find they are confused about what a client contains, you can create a spec for it. And on and on...

thank you again, this is great

No problem. It can be hard in the beginning to peel the onion. I came from OOP as well, and I think your question is just normal, everyone who does has it, we're almost too used to complexity 😛, that we find it hard to think without it

really, for me, the worst part is that the concept of a "client", as an object with state and behavior, is accomplishing nothing. the pattern of simply grouping together the data that happens to be shared gets you all the practicality and none of the useless abstraction

@U0K064KQV I was going through this thread as I am in general interested in patterns. About treating a namespace as a poor man's class, do you actually use it in production code? I think the aspect of multiple instances of client class with independent states is lost with this approach. All you have is a global shared state.

@UJRDALZA5, if I understand the thread, I think that would be true if there were defs in the namespace containing the state. But I don't think he's suggesting that. Rather a map contains the state and is passed to each fn. So there can be any number of maps (OO instances).

You are right! I assumed the all in "shove it all there" included state.

Ya, @UBRMX7MT7 is correct. The pattern here is that "make-client" acts as a constructor for instances of your data.

This is really interesting to me. Not really seeing the difference between getting values (“state”) from a function vs. from a variable of some kind. In both cases it’s a symbol that evaluates to values. Help? 😳

But, some use cases in OOP make use of static fields. And in clojure, those would just be global defs

@UCW3QKWKT Hum... imagine you have a Contacts app where the user can create new contacts.

You can't just do:

(def contact
  {:name "Joe" :phone 2223345})

Because, the user will be adding contact dynamically, at runtime. They could add from 0 to n of them, who knows

And you can't predict what name or phone the contacts are going to have. So what you need instead is a way to both parameterize your contact map, but also possibly create many of them, all with different names and phones

You can do that with a function

(defn make-contact [name phone]
  {:name name :phone phone})

So now when the user press "Add contact" and enters a name and phone on the form and clicks submit, you can use make-client to dynamically create a new instance of a contact

Does that make sense?

With a def, you need to know the values ahead of time, and how many unique contact you'll have.

But with a defn, you don't, you can wait till runtime and then use it to create as many of them with whatever values as you want.

But we can have a (def contacts (atom [])) . For any non-trivial apps, I think there will always be a giant state map anchored to some namespace somewhere.

You often don't need one actually

A lot of apps will store the states straight into a DB of some sort. And some others can just carry around state through from start to finish, including long lived apps by using recursion

But yes, some will. But that would be in the containing component.

DB is just an extension of what I said. The data has to be anchored to something. But I am very curious about the other thing you said.

And some others can just carry around state through from start to finish, including long lived apps by using recursion Please expand on it if you have the time.

For example:

(def contacts (atom []))

(defn on-new-contact [name phone]
  (swap! contacts conj (make-contact name phone)))

I recently answered something similar here: https://clojureverse.org/t/functional-thinking-managing-state-boardgame/5478/5?u=didibus

But a def is still anchored. I thought there's a clever trick here.

Sorry, my example in slack was for: "But yes, some will. But that would be in the containing component."

The link to clojureverse shows how to carry over state

Guess I am typing too quickly.

And me too slowly 😋, doing all this from a phone is hard

With the functional approach, there are even some DBs that are implemented like that. If you ever heard of a log store, or an append only store. Basically, you keep carrying last state and making new states out of it, never mutating, and once in a while you just delete the history you no longer need to save on memory/space.

Nice explanation there in the linked article! You can encapsulate even more by passing a make-board fn in there instead of the init-board. But you might already be doing that, since you only shared the loop/recur part.

Yup, definitly. If your initial board needs to be parameterized that be a good idea. Like say on "New Game" you took some options, type of game, size of board, who knows

This might be related: https://stackoverflow.com/questions/5839697/why-is-the-use-of-maybe-option-not-so-pervasive-in-clojure

A point of terminology, a var is something created by a def, a global definition, those are pretty much never nil

A name bound by let or a function in clojure is called a local, and those are indeed sometimes nil

So, the way its done in Clojure, is that absence is represented by the key being missing from the map

You can do that, because of how dynamic the data constructs are

So you have two concepts. First is the data is missing, that would be represented as the key isn't even there. The next one is, the data is there, but its value is nil. That would be represented with the key being there but having a value of nil

So say you had person maps, and sometimes those have a name and an address, sometimes only an address.

You would have:

{:name "Joe" :address "123 bla"}

{:name "Joe"}

{:name "Joe" :address nil}

Oh, and to specify the semantics of a particular map, Spec would be used. You can say which key are mandatory, which are optional, and which are allowed to be nil or not

Though sometimes, simply doc or comments are used, or even its just not specified if its kind of obvious from context

I like how readable this approach is

I'll go ahead and implement this in expectations.clojure.test tho'...

cool! Thanks!

best options are hard to tell rsrsrs. I like reitit now o/// #reitit

Okay, maybe best options is a little too much to ask, my bad hehe I'll give this one a look, thanks!

I use reitit too

What a co-incidence, I just wrote this today: https://github.com/borkdude/babashka#print-random-docstring

That's quite useful actually. Sometimes I forget the less used fns.

I swear I didn't see that thing before I wrote the script 🙂

It was a massive co-incidence!

I saw your posts too and I was like "wow!"

I did see the idea here before: https://github.com/tomekw/cotd

Hi Behrokh, not sure if you already solved the issue, but it's a problem with Cursive and it's fixed in EAP only. If you don't want to download that, you can fix like this: Go to Build Tools -> Clojure Deps: Use private repo: ID: Central / URL: https://repo1.maven.org/maven2/ Then refresh and download.

thanks @U7JCZJR0W I was suffering the same.

thanks @U7JCZJR0W it’s working now.

People might be able to help more if you describe what is and isn't working. When you run your code what does it do that you didn't expect? What do you want it to do?

I used Emacs decades ago, back in the 17.x/18.x days. I moved away from it round about 19.x I think. I started using C++ IDEs then Java IDEs. Eventually, after a bunch of languages, I ended up in Clojure and went back to Emacs because it was the "best" / "most popular" -- and was shocked that it hadn't changed much in... twenty years?

I went back and forth between Emacs and other editors for a while, when learning Clojure, then settled on Emacs... until I saw Atom/ProtoREPL at Conj one year! I switched to Atom and never looked back. ProtoREPL is no longer maintained (and I think it's actually broken in recent Atom releases?) but I switched to Chlorine over a year ago and I love that combination (Atom/Chlorine, plus Cognitect's REBL data browser, with a simple Socket REPL -- no nREPL etc).

curious, why not the socket prepl?

@U4R5K5M0A I think Chlorine starts a prepl once it has a plain socket connection.

The socket REPL is nice because you can a) telnet/netcat to it from your phone b) connect to it via unrepl/unravel c) connect from Chlorine ...