Fork me on GitHub
#beginners
<
2018-05-02
>
orestis00:05:53

@noisesmith any examples in the wild of how that would like? I mean a closure that maintains mutable state and exposes an API...

noisesmith00:05:29

a rough skeleton is (defn make-connection [config] (let [state (atom nil)] (reify connection (connect [opts] (reset! state (do-connect (merge config opts))) (connection [] @state) ...)))

noisesmith00:05:19

probably make connect return nil so people don't try to use the value it returns instead of the wrapper, use try/catch in each method to recover and reconnect (or fail in a defined way) etc.

noisesmith00:05:40

sorry, no really good example in an open source project I can think of right now

orestis00:05:24

Where connection there is a protocol, right?

noisesmith01:05:51

right, exactly

noisesmith01:05:18

in clojure in order to implement proper methods you want a protocol or interface

noisesmith01:05:45

oh also that usage of reset! and even putting the state in an atom are both actually bad - atoms are made for immutable data and can misbehave badly when they contain mutable things which means you need to mess with locks most likely D:

Andrew10:05:27

Hi guys. Would it be wise to dive into Clojure without any actual Java/JVM knowledge? I have only C++ & Python on my back, and almost completed SICP, should I at least read some book on Java before going full Clojure?

alan10:05:45

Hi, I recently started programming in Clojure and I come from an R/Python background, but no Java whatsoever. I didn't have many issues. Lately I'm starting to understand better the JVM, Java and compilation options because I'm starting to use Clojure at work and I would like it to be flawless (as much as possible :)

gklijs11:05:16

Reading a book on java before going to Clojure isn’t needed. When you start thinking about running it in production it would be useful to know some more about the jvm, like how to manage the memory, and maybe how to monitor.

Andrew11:05:16

Thanks for your advice you guys! @UAE4G28HX Glad to hear this path is possible 🙂

dadair21:05:16

Is it safe, in terms of sorting/order, to do (zipmap (map :id xs) xs)? Or is there potential for the id to actually be incorrect for a given x?

dadair21:05:12

Versus a (reduce (fn [m x] (assoc m (:id x) x)) {} xs)

noisesmith21:05:55

@dadair I can't think of any collection type for xs that you would reasonably be using that would change order when used twice

seancorfield21:05:11

I believe it is safe, since (keys m) and (vals m) are guaranteed to produce the same order, as I recall (for the identical m).

noisesmith21:05:31

but keys and vals don't come into play here

seancorfield21:05:33

Another option to consider for that, by the way, is (into {} (map (juxt :id identity) xs))

noisesmith21:05:45

yes, I like the juxt version better personally

seancorfield21:05:58

@noisesmith No, I'm just applying an extension of the logic behind that guarantee (about keys/`vals`).

alexmiller21:05:01

Everything is based on seq order, which is stable

seancorfield23:05:03

BTW @dadair The fastest solution (for large sequences of maps) seems to be (into {} (map (juxt :id identity)) xs) -- note the parens here: it's using the transducer version.

seancorfield23:05:36

(that's faster than both the reduce and into/map above)

dadair23:05:49

Great, thank you all!