by the way, the existing code base was created by other people, not me
On Wednesday, November 25, 2015 at 9:40:11 AM UTC-8, fah...@gmail.com wrote:
>
> 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.
