[Eventmachine-talk] eventable experiment and application-level

Tony Arcieri
Wed, 13 Feb 2008 13:17:20 -0000

On Feb 13, 2008 1:40 PM, James Tucker <jftucker at gmail.com> wrote:

> I took a look at Eventable when I needed internal event processing, or
> at least, a centralized ''listen for event'' system.
>
> It''s possible to do this all kinds of ways, I simply use a hash
with
> some syntax sugar tacked on.
>
> I didn''t use Eventable if i remember correctly, because:
>
> a) I had no idea if it was being used somewhere else
> b) the implementation is either missing or outside of ruby?
> c) There is no way to remove event handlers
> d) Some of our handlers for some apps are growing to resemble
> something that plays a logical part not too far detached from a
> ''controller'' from an MVC stack.
>
> So I defined everything ruby side, using as I say, a hash plus some
> syntax sugar.
>
> For the implementations with fatter handlers (something larger than a
> proc or Method to call), I also provided a mechanism for auto-
> discovering the handlers. (At this point, it really does start to
> resemble controllers).
>
> A simple starter:
>
>
> Handlers = Hash.new { |h,k| h[k] = [] }
>
> class <<Handlers
>   def handle(name, *args)
>     self[name].each do |h|
>       begin
>         h.call *args
>       rescue
>       end
>     end
>   end
> end
>
> Handlers[:my_event] << proc { puts "my event occurred" }
>
> Handlers.handle(:my_event)
>
> pr = proc { |arg| puts "event2: #{arg}" }
> Handlers[:my_event2] << pr
>
> Handlers.handle(:my_event2, ''test'')
> Handlers[:my_event].delete(pr)
>
> :"salt to taste."
>

That''s starting to look an awful lot like the Tasks / Channels approach
to
concurrency in Rubinius, except asynchronous.

--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
-------------- next part --------------
An HTML attachment was scrubbed...