Indexed event listeners

[reenl]

I pretty much made this PR to start a discussion.

In this PR:

• Indexed listeners.
• Listeners cannot be added twice. Define behavior for adding the same listener many times #7 is related.
• Performance of removeListener is significantly improved with a lot of listeners O(N) to Olog(N).

Bug in this PR:

• With once a duplicate listener can be added. (This is fixable).

Do you think this is a common use case and are you willing to support it? If so, we might want to make a different trait, so you can choose whatever case suits your project best.

[igorw]

Slightly related: I have had objections to adding priorities in the past, see also #5.

But I'm not opposed to having an index if you can demonstrate the performance is significant (just add a perf script to your PR).

[reenl]

Here we go.

https://gist.github.com/reenl/6015521

reen@vm01:~/evenement$ git checkout 4164980b8ae5d1d8de341868aa00230c05c88e7c
...
HEAD is now at 4164980... Merge branch '1.0'
reen@vm01:~/evenement$ php performance.php
Cost adding events: 15.472888946533MS
Cost total: 603.03211212158MS
reen@vm01:~/evenement$ git checkout master
...
Switched to branch 'master' (my forks master that is)
reen@vm01:~/evenement$ php performance.php
Cost adding events: 29.232978820801MS
Cost total: 72.31593132019MS

[reenl]

@igorw

I've been thinking about this, but the performance isn't really an issue because it isn't a common use case at all.

However, if you decide to disallow multiple instances of the same listener within your emitter ( #7 ), then you could use this logic to see if the listener has already been added.

[WyriHaximus]

@reenl Hey, I've taken over maintenance for this package. And I'm unsure about this PR honestly, are you still interested in this feature or should I close this PR?

[reenl]

You can close it :)

[WyriHaximus]

Alright, thanks for the quick response 👍