Hi! 2014-12-09 18:08 GMT+01:00 Andy Dwelly <andydwe...@gmail.com>:
> Looking through my recent work I see that a number of atoms, swap! and > reset! calls have snuck into my work, usually when there's an expensive > operation like reading and parsing a large file or connecting to a > database. I find I'm doing things like > > (def conf (atom nil)) > > (defn config [] > (if (nil? @conf) (reset! conf (read-and-expensively-parse > "somefile.xml")) @conf)) > > So that the first time (config) is called it will do the operation, but > future attempts will simply deref the atom. > > Recent discussions here alerted me to memoize which will do this without > the atom, but the documentation mentions that the functions that are > memoized should be referentially transparent. Although I'm pretty sure that > while my server is running, the config will not change - it can't be > guaranteed in a formal sense. Reading a file or connecting to an external > process is doing io of course, in theory someone could change the file > while my back was turned. > > Questions: if I was prepared to live with the consequences of having to > restart the server if the conf file had been changed, would it be more > idiomatic to use use memoize to avoid mutating state? > If I really had to change a conf file while the server was running, is > there any way a memoized function could have it's cache cleared? I suspect > the answer to that one is no - but you never know.... > > In my opinion, if you assumes the consequences of having to restart the server, delay is the best solution for it. As far as I know, it guarantees one unique execution regardless how many threads are dereferencing it, and subsequently it always returns the computed result. My two cents. Andrey > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
