On 3 March 2010 04:34, Sophie <[email protected]> wrote: > As a bit of a newbie to the functional + identity/state design space, > I'm struggling a bit with where to use identity constructs (refs) and > where to stay with pure functions, and could use some guidance. Pardon > me if some of my terms are a bit off. Here is a simple hypothetical > app for matching Applicants to Jobs. > > I have several Applicants, each with some set of Skills. There are > several Jobs, each with some Requirements. There is some Match > relation between Skills and the Jobs they can match. The set of > Applicants, each of their skills, and the set of Jobs can change with > time. There is a set of Jobs that each Applicant can fill, > functionally computed from applicant skills & job requirements & > Match. > > Ok, so jobs_that_an_applicant_can_fill is a pure function, I get > that. > > 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? > > Can each Applicant have a "skills" ref, whose state changes to > different sets of Skills? Should I design it this way? > > How do I choose? What are the trade-offs?
If you have a single value representing the whole world, then it seems that protecting it with an atom would be the simplest and most idiomatic solution. Refs are for co-ordinated change, i.e. where you want to update multiple values at the same time. For a single value there seems to be little reason to adopt refs, though I've often wondered why Stuart Halloway's book gives an example updating a single ref of messages for a chat application. If you partition your data more, into several values, then you should use refs to co-ordinate the change. The more granular you make the refs, the more you trade complexity of design for potential throughput under concurrent load, as finer grained refs are likely to mean less collisions during transactions (unless of course you update every ref in every transaction - which sounds like it'd be the worst case scenario). R. -- 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
