Target both evenement 3 and 2

[WyriHaximus]

Événement 3.0 is nearly fully backwards compatible with 2.0. It packs some neat performance upgrades without any code changes on nearly all projects using it. Took a quick look at your code base and couldn't find any breaks .

[coveralls]

Coverage remained the same at 100.0% when pulling c950e4e on WyriHaximus-labs:evenement-3.0 into b410b6e on mkraemer:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 983d478 on WyriHaximus-labs:evenement-3.0 into b410b6e on mkraemer:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 983d478 on WyriHaximus-labs:evenement-3.0 into b410b6e on mkraemer:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 04119c8 on WyriHaximus-labs:evenement-3.0 into b410b6e on mkraemer:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 04119c8 on WyriHaximus-labs:evenement-3.0 into b410b6e on mkraemer:master.

[mkraemer]

Thanks!

I had to adapt the internal event handling to make sure that the argument which is passed by pcntl to the callback registered with pcntl_signal is not further passed to EventEmitterTrait::emit, as the latter breaks in case an associative array is used as argument :)

[mkraemer]

Yes, exactly. call_user_func_array was used in evenement 2 which silently dropped the named keys of the associative array while the splat operator used in evenement 3 refuses to work at all.

I didn't realize arguments were passed at all and assume nobody relies on them being present, but I'll tag a new major version for this potentially breaking change.

[WyriHaximus]

I didn't realize arguments were passed at all and assume nobody relies on them being present, but I'll tag a new major version for this potentially breaking change.

Neither did I hence my surprise seeing your commits. Tagging a new major version sounds like the reasonable thing to do 👍