On Wed, 3 Mar 2010 14:20:56 -0800 (PST) Armando Blancas <[email protected]> wrote:
> > > On Mar 2, 8:34 pm, Sophie <[email protected]> wrote: > > Do I design a single "World" ref whose state changes with time to > > different worlds, so adding a new Applicant or even adding a new Skill > > to an existing Applicant results in a new World value? Or is it better > > to have an "Applicants" ref and a "Jobs" ref that refer to different > > sets of those er.. things? > > > > It's simpler to use refs close to the object that will change; that > makes > the code to mutate the value simpler; if the world is the only mutable > object, > then the code to change something in there will increase with the > depth > of the mutation. I'm not sure it's simpler: update-in makes reaching deep into a structure to create a new structure with that one change in it easy, and is probably more efficient than trying to do the same thing by hand. More importantly, if you break your refs up into smaller objects, you should get better concurrency, as you can change two such refs in two different threads without a problem. If you put the two in a structure in the same ref, then you can't update one while the other is being worked on. <mike -- Mike Meyer <[email protected]> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
