Closed faultyserver closed 8 years ago
Semantics 👍
Does this make any functionality easier for you to implement? It looks like a pretty simple change, but if it's going to require nontrivial refactors, I would keep this low priority until it blocks something else.
The example I gave is exactly why I brought this up.
In Serializer
, I need to map arguments to their serialized form. The most efficient/dry way to implement this is as a default_event_handler
, which doesn't allow me to do out-of-place assignment to args
(as shown in the example). But, with the Event
wrapper, it would.
The refactors are all pretty trivial: Find/replace args
and kwargs
in middleware classes with event.args
and event.kwargs
, and change all of the function/block definitions to take event
rather than channel, args, kwargs
.
I see. Thanks for clarifying!
Closed by #18.
Right now, when an event gets sent up the middleware stack, the
call
method takes a specific set and arrangement of arguments:This could be simplified and made more powerful by wrapping everything up into a
Shark::Event
class. With that, thecall
definition would be much simpler:Additionally, the semantics of argument collectors (
*
, and**
) can be avoided, as everything will be wrapped up intoargs
andkwargs
attributes onEvent
.A basic outline of the class would be
Another advantage of using a wrapping class is that arguments can be freely modified out-of-place. Currently, modifying arguments either has to be done in-place (which only works in some cases, e.g.
args.map!{}
), or a replacement has to be specified when proxying an event up the middleware stack. This gets troublesome with event handlers, because there is no way to replace an argument (using=
instead of bang methods) and have that change persist outside of the handler. For example:With an
Event
class, this would look and work differently:The only thing that doesn't work here, is replacing the entire
event
object, which would be undesirable anyway.