You keep talking about performance. I'm a long way from being a clojure expert, but one thing I *do* know is that premature optimization is the root of many many evils.
May I suggest you first get your app working, in a clean understandable fashion, ideally with some solid unit tests. Then, and only then, profile it, work out if it performs adequately, and optimise the parts that need it? (apologies if this is the approach you are already taking - it's bit clear from your posts if that is the case) - Korny On Jun 14, 2012 7:53 PM, "Jim - FooBar();" <jimpil1...@gmail.com> wrote: > On 14/06/12 10:01, nicolas.o...@gmail.com wrote: > >> There should not be any atom in this. The function would be more >> reusable if it take a board and return >> a board without changing any atom. >> (You will still be to express the atom change around it but you could >> also use to try and build a tree without undoing >> anything.) >> > > Yes you are right nicolas...I really don't need to reset! the atom > inside 'move'...It has been addressed... > > I don't think this approach is extensible enough. You will want to >> implement more games later. >> So maybe a good thing is to use protocols or multimethods to represent >> game rules. >> The atoms should disappear until later. (You are building a library of >> moves and rules, there is no notion >> of state in that. Only when you use it for playing a game on a GUI you >> will need a state) >> > > I don't want to involve multi-methods in this particular project for > performance reasons...I do get your point but current-items is only > fetching the atom or the derefed atom from a game...more game means adding > a clause so it fetches the appropriate pieces...game rules will be > implemented in core.logic it has nothing to do with this fn. I do agree I > will only need the atom when playing an actual game though... > > > Jim > > > -- > 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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/**group/clojure?hl=en<http://groups.google.com/group/clojure?hl=en> > -- 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
