> > If you make a design decision to use an atom, you are effectively committing
> > to never, ever being able to update that atom within a transaction.
> > refs can do everything atoms can do and more. They are slightly slower,
> > perhaps, but much safer. So
> > unless you have an explicit pe
On 5 March 2010 17:56, Mark Engelberg wrote:
>
> On Wed, Mar 3, 2010 at 5:20 PM, Rick Moynihan
> wrote:
>>
>> 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.
>
>> For a single value the
When you increment the contents of an atom, for example, it happens
immediately. If it is inside a transaction, and the transaction retries,
the contents will be incremented multiple times. Refs, on the other hand,
retry from the initial state at the beginning of the transaction, so as long
as th
On Fri, Mar 5, 2010 at 4:08 PM, eyeris wrote:
> I don't follow your logic. Modifications of refs within a transaction
> retry too.
>
He's saying that atoms don't participate in the STM. If an atom depends on
the value of some refs, your program might be put into an inconsistent state
if the tran
I don't follow your logic. Modifications of refs within a transaction
retry too.
On Mar 5, 11:56 am, Mark Engelberg wrote:
> On Wed, Mar 3, 2010 at 5:20 PM, Rick Moynihan wrote:
>
>
>
> > If you have a single value representing the whole world, then it seems
> > that protecting it with an atom w
On Wed, Mar 3, 2010 at 5:20 PM, Rick Moynihan wrote:
>
> 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.
...
> For a single value
> there seems to be little reason to adopt refs, ...
I
Someone could (and hopefully will) write a multi-hundred-page book
exclusively on Clojure's approach to state. I simply didn't have
enough space while overviewing the whole language.
If you want an identity that is isolated from whatever else is (or
might in the future) happen in your app,
Thank you all, the replies so far and the questions have already
deepened my understanding considerably!
Looking forward to more. I think a bit more discussion like this (not
necessarily my quite skimpy example) would be quite valuable to many
like me.
--
You received this message because you ar
On Mar 2, 11:34 pm, Sophie wrote:
>
> How do I choose? What are the trade-offs?
>
> Any and all guidance, insights, advice etc. welcome!
>
> Thanks!
To me, it seems like you have two orthogonal pieces of data, and a
function that builds a report from that data. You have a set of job
listings,
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.
I seem to recall atoms being the last reference type to be introduced.
They might not have existed
On 3 March 2010 04:34, Sophie 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
On Wed, 3 Mar 2010 14:20:56 -0800 (PST)
Armando Blancas wrote:
>
>
> On Mar 2, 8:34 pm, Sophie 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 W
On Mar 2, 8:34 pm, Sophie 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 th
One aspect of your question that makes it difficult to answer is that
you don't explain what the repercussions should be (in terms of
synchronization) when a new applicant or job enters the pool or a new
skill is attributed to an applicant. Should the job<->applicant
matching function be restarted?
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 App
15 matches
Mail list logo
