Context binding feature about tseep

[lpinca]

No, thank you. I actually don't need the feature as I'm not planning to use an external dependency for the EventEmitter. Maybe for the browser but I'm not writing any front-end code at the moment.

[Morglod]

Found only one solution without impact on performance.
The problem is that any change around context binding inside hot path (.emit) results in bad JIT code & allocations.

Added addListenerBound / removeListenerBound that binds listener to EventEmitter or other specified context.

552b310

[Morglod]

I agree that I should write something like (not drop-in replacement for node's eventemitter).

But there is nothing "fundamental" in it.
Its some strange anti-pattern as most of other "fundamental" things in node's emitter, which no one should rely on.

[lpinca]

Its some strange anti-pattern as most of other "fundamental" things in node's emitter, which no one should rely on.

That is your personal opinion which I respect but I disagree. It is feature present since the early days of the EventEmitter and is heavily relied on in Node.js core and many user-land modules. It allows to avoid calling Function.prototype.bind() every time.

[Morglod]

There are also 'newListener'/'removeListener'/'error' events which also presents since the same early days. Which I think is more useful than this fundamental thing, but ee3 has no implementations for this.

Without this fundamental thing, you could just:

ee.on('foo', function () {
  const self = ee;
  // do whatever you like
  assert.strictEqual(self, ee);
});

Could you give please some examples of packages which rely on this thing?

[lpinca]

Some examples on top of my mind are:

• https://github.com/pinojs/thread-stream.
• https://github.com/websockets/ws (I am a maintainer).

Without this fundamental thing, you could just:

Which means using a wrapper function for every listener just like Function.prototype.bind().

[Morglod]

I see, thanks for links!
So real example is inheritance thing where you have no reference to instance other than this.

I dislike inheritance thing, but agree that its common pattern everywhere
Will try to implement it (or make some kind of "compatibility" version)

Do you have any other missing features needed?

[mustafa519]

Fixing this issue will break the __proto__ = null optimization?

Well, I mostly have to bind the instance otherwise it causes Cannot read properties of undefined (reading 'events') error. Especially, if I need to pass the events variable, which was defined as EventEmitter instance.

So, if it kills the optimization, what would you suggest instead? Or would you consider adding an option like autoBind: true?