Support emitting multiple arguments

[tunnckoCore]

Just like .emit('foo', 1, 2, 3). Initially thought for rest + spread but it adds around 50 bytes.
So I think it may be enough to have explicitly defined 3-4 arguments

That adds 4 bytes.

    emit(type, a, b, c) {
      list('*').concat(list(type)).forEach( f => { f(a, b, c); });
      return ret;
    }

Some faster implementations than node core's uses this tactic, but up to 6-8 args

[tunnckoCore]

So finally, I just tried to see what I'll get if I merge everything ( #8, #11, #12 + this one #13 ) and it is 210 bytes which looks good number :P :)

[developit]

Nice! Though I might have an interesting thought that changes your mind about the multiple arguments thing from @bevacqua:

[tunnckoCore]

hmm.. yep, forgot about that

[Aaronius]

FWIW, I would use support for multiple arguments before using *.

[developit]

You might be surprised how convenient * is! Some uses I've had for it over the years:

• logging (example: on('*', console.log))
• refiring modified or aggregate events (example: on('log:debounced'))
• collating events between two emitters (example: inside/outside a worker)
• implementing rudimentary event bubbling (listen to child's *, refire if e.bubble)
• even implementing case-insensitive event handling 💃

[tunnckoCore]

I'm absolutely agree. Working (emitting) only one argument is cool and very clean. So yea, I can agree to remove that extra second argument from #19, but we should mention that in the docs that emit can only emit one argument. :)

[bevacqua]

You can easily do both.

• .emit(type, ...rest)
• .on(type, (type, ...rest) => {})
• .on('*', (type, ...rest) => {})

[tunnckoCore]

Yea. Closing per f4c60f4