The ... rest operator and Signals

[Jay Proulx]

Hey All,

Here's my business case, I'm sure there are more. I need a proxy
between a signal driven Delegate, and an AsyncToken service
implementation... Which just happens to live in Swiz.

Here's my SignalAsyncToken:
https://gist.github.com/804610

Here's my updated Signal.as:
https://github.com/pollensoft/as3-signals/commit/8617ad6c8a7cd452a7c528b2d72bddb739bd7a83

I have 2 concerns with my current implementation: safety and
performance.

Has anyone done any testing regarding exactly how much faster it is to
call execute0(), execute1(...), execute2(...) vs execute() every time?

Safety wise, this bypasses checks where you might have accidentally
forgot to add signal parameters, you'll likely get standard runtime
errors if your signal fires and tries to pass arguments to a method
that actually has no parameters.

The other option is to modify signal.add() to include a
hasRestParameter:Boolean argument, and check for that through each
iteration within Signal::dispatch(...) and call execute() if we see
that the Slot::hasRequestParameter. This way you have to specifically
acknowledge that you want Signal to skip the argument length check.
This seems a little bit hacky to me, but might be acceptable.

This implementation can be useful for all the same reasons as a
generic Event handler (ever wanted to capture every event just to see
what's happening?)

Open discussion and new approaches welcome :)

[Tyler Wright]

Jay,

In my tests of 1 listener, function.apply was faster then the switch statement optimization. I can see how the optimization would be faster with many listeners, but I still favor the simpler approach of avoiding execute0..2. Which makes me hypocritical because I complicate my own code for performance reasons. :)

I like the idea of being able to support listener(...params)

Tyler