Thanks for all the replies so far. You're right, there is state involved. 
My situation is this:

   1. there are several different kinds of triggers (like phone, doorbell, 
   email, SMS)
   2. there are business rules about who should answer and what they should 
   do in response (Bob vs Jane answers, make a pizza vs make a cheeseburger, 
   put it in the mailbox vs toss it out the window)
   3. the application of said rules depends on 
      1. config items
      2. what may have happened already ("whenever Bob has done X, Jane 
      should refrain from Y", Zoe always sneezes at time Z after which it is 
too 
      late to do A, etc)
   4. need to Do the Right Thing even if a chaos monkey causes our process 
   to restart
   5. meat-space:
      1. I'm the only one on the team who knows any ClojureScript so 
      there's probably a strong team inclination for avoiding it
      2. The existing code base (shell, C, C++) is viewed as awful by 
      everyone. They believe that, if Done Right, C++ should be sufficient.
      3. I'm the *junior *guy who will be doing all of the actual coding 
      and I prefer functional lispy style.
   
On Wednesday, November 25, 2015 at 9:14:00 AM UTC-8, Stuart Sierra wrote:
>
> Hi,
>
> Channels are many-to-many in the sense that many processes can "put" 
> values on the same channel, and many processes can be waiting to "take" a 
> value. They are one-to-one in the sense that each "put" value will be 
> delivered to exactly one "taker".
>
> What you're describing sounds like a typical Observer pattern, which 
> implies some state to keep track of "subscribers." You could implement 
> something like this with channels using mult/tap or pub/sub, but it's not 
> expressed directly in the core.async APIs.
>
> Depending on the use case, doing it with channels may or may not be easier 
> than implementing an Observer-style pattern directly. But having tried to 
> implement an Observer once or twice, I've learned it's hard to get all the 
> edge cases right, so now I find channels easier to understand.
>
> –S
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to