2014-03-09 14:21 GMT+01:00 J. Pablo Fernández <pup...@pupeno.com>: > > > On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote: >> >> Hello, >> >> To be honest I don't see any fundamental difference between your first >> attempt and the improvement: both share the fact that the mutation of the >> state happens within the draw function. So in both cases, you have a >> temporal coupling between updating the state of the app and rendering a new >> view of the app's state. >> > > Yes, what's happening in both cases is very similar, but the function draw > in the "functional" style, in my opinion, is easier to read and maybe it's > also easier to test. > > >> I would suggest that you don't swap! at all within draw, just deref and >> render the result of the dereffing. >> >> And, in another thread, at potentially a totally different pace than the >> redrawing's pace, update the application's state accordingly to business >> rules / constraints. >> >> Schematically, something like this: >> >> (def app-state (atom (init-state))) >> >> (defn draw [...] >> (let [app-snapshot (deref app-state)] >> ... call quil primitives to render the application state snapshot >> ...)) >> >> (future >> ... logic which updates the app-state atom depending on business rules >> / constraints, in a separate thread ...) >> > > I never worked with future, this is exciting, but I have some questions. > Do you mean that future is completely separate from draw? I'm just getting > started, but draw is not only a function to draw, but as a side effect is > the clock of the app, as it's called according to the set frames per second > and you normally *take a step* en each draw. Would draw create these > futures for the next draw? >
future is just a detail in what I was trying to explain. If your logic ties the frame rate and the stepping function, then forget about what I was suggesting. You just will have to ensure that all your logic+rendering time is below the app's clock rate, of course. > -- > 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. > -- 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.
