"Jim - FooBar();" <jimpil1...@gmail.com> writes: >> If the things you store in atoms or refs aren't immutable, then the >> guarantees made by those reference types simply don't apply. > > hmmm...I see what you mean. I'll try to rethink my design... In fact, > I was wondering in the beggining of this project whether I need > java.awt.Point or not and I decided that I needed it cos I want to > eventually make a gui and a lot of methods in Swing take Point > args...I'll think about how else I can do it...
Your logic and representation should be separate from your GUI rendering code. > Does what you said mean that resetting or swapping the board atom will > not be atomic if the pieces have mutable state? No, swap! stays atomic of course. But you can change the object stored in the atom without using swap! at all. ,---- | user> (def world (atom (java.awt.Point. 0 0))) | #'user/world | user> @world | #<Point java.awt.Point[x=0,y=0]> | user> (.move @world 17 23) | nil | user> @world | #<Point java.awt.Point[x=17,y=23]> `---- Although `world` is an atom, I changed it without swap!. > I guess I could leave Point as it is but instead of doing > 'setLocation' I can return a brand new Piece with a brand new > Point...it will still be mutable but there will be now way of mutating > it...how does that sound? I'd represent the location of a piece as a plain vector [x y] (or a map {:x x, :y y}) and have a function in the gui-namespace like (defn piece->point [p] (let [[x y] (location p)] (java.awt.Point. x y))) where `location` was an IPiece protocol function that simply returns the location of a piece. Bye, Tassilo -- 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