is there a reasonable concept of using WeakRef for listeners?

[christopherreay]

So if we add a listener using a WeakRef option, then the listener function will not be called and will be automatically removed from the listener list?

Would probable require some kind of checks when determining if to send the event to the listener

Should work generically for all types of listeners, sync and async etc.

What do you think about this? Does it make sense?

[DigitalBrainJS]

@christopherreay Are you talking about introducing a WeakMap instead of a plain object to store event handlers for the potential ability to auto-dispose of listeners?
If so, this won't work at all. WeakMap requires object keys since primitive types can't have a reference that could be 'weak'. So in this case we can't fire an event by its name (a plain string), because the event name must be an object reference, and this reference we will have to store somewhere to be able to handle events. Moreover, we will have to control its value manually to be garbage collected and can't iterate over its elements. In other words, WeakMaps is not suitable for this task.

//pseudo-code
let event= {}; //event reference;

const ee= new EventEmitter();

const handler= ()=> console.log('hello1');

ee.on( event, handler);

ee.off( event, handler); // we can't iterate over WeakMap elements, so handlers are still stored in the array data structure.

ee.on( event, ()=> console.log('hello2'));

ee.fire(event, 123);

// event= null; // Where we should do this?

// what about exporting event 'names' to be handled from outside? Where and how it can be set to null?
module.exports= {
  readyEvent: event; ??? // reference leakage
}

[christopherreay]

not "instead", but as an option I fully bow to your understanding, but I don't understand yet. so why can't we store the objects in an array, one for each event type? and just iterate through the list to fire them? oh something that may be relevant, I read a couple days ago that "WeakMap" and "WeakSet" didn't really solve the weak ref here: weakref : "A primary use for weak references is to implement caches or mappings holding large objects, where it’s desired that a large object is not kept alive solely because it appears in a cache or mapping. For example, if you have a number of large binary image objects (e.g. represented as ArrayBuffers), you may wish to associate a name with each image. Existing data structures just don't do what's needed here: - If you used a Map to map names to images, or images to names, the image objects would remain alive just because they appeared as values or keys in the map. - WeakMaps are not suitable for this purpose either: they are weak over their *keys*, but in this case, we need a structure which is weak over its *values* *"* but I can see you are right that they don't apply here because there's no way to know if there are zero strong references remaining to the listener object. your solution of "objectify" is great. nice library I learned from the "return promises.all" is a great way to interleave sync and async code. thanks

…

On Sun, 21 Mar 2021, 14:38 Dmitriy Mozgovoy, ***@***.***> wrote: @christopherreay <https://github.com/christopherreay> Are you talking about introducing a WeakMap instead of a plain object to store event handlers for the potential ability to auto-dispose of listeners? If so, this won't work at all. WeakMap requires object keys since primitive types can't have a reference that could be 'weak'. So in this case we can't fire an event by its name (a plain string), because the event name must be an object reference, and this reference we will have to store somewhere to be able to handle events. Moreover, we will have to control its value manually to be garbage collected and can't iterate over its elements. In other words, WeakMaps is not suitable for this task. //pseudo-code let event= {}; //event reference; const ee= new EventEmitter(); const handler= ()=> console.log('hello1'); ee.on( event, handler); ee.off( event, handler); // we can't iterate over WeakMap elements, so handlers are still stored in the array data structure. ee.on( event, ()=> console.log('hello2')); ee.fire(event, 123); // event= null; // Where we should do this? // what about exporting event 'names' to be handled from outside? Where and how it can be set to null? module.exports= { readyEvent: event; ??? // reference leakage } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#274 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB2PPQUTL5XNXOEL5P4L5LTEYAFXANCNFSM4ZOARNMA> .