Just to avoid misunderstanding ... > without even reading what DOM had to offer before
I meant it went out through a pragmatic approach with a non Events based emit model and few inconsistent choices regarding listeners in terms of both interface and the inability to interfere with non owned ... we need a better approach to EventListeners if it has to be implemented in core, something that could work in both client and server world. Again my 2 cents On Mon, Jun 1, 2015 at 10:58 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > -1 > > not only node implemented EventEmitter without even reading what DOM had > to offer before, I see whatever EventEmitter proposal would land in ES7 > something related to lightweight traits, and not a class to extend. > Extending EventEmitter without having the ability to extend something else > looks like a poor choce to me, having a list of well known traits including > the EventEmitter one would be better. > > About current node implementation: > > 1. it doesn't accept objects as listeners, a not so common but actully > widely used practice on the WEB > 2. it does accept multiple times the same listener, a footgun on > DOM-land > 3. it has a maximum amount of listeners per objects, a footgun on > DOM-land > 4. it has an `on` method but not an `off`, not convenient on DOM where > an app doesn't have same listeners forever due Ajax/client<->server > interaction nature, I'd like a more consistent naming convention > 5. it exposes the ability to remove/retrieve listeners you don't own, > again a footgun on DOM or anywhere the code is own by multiple libraries > and authors > > Just my 2 cents. > > Regards > > > > On Sun, May 31, 2015 at 6:46 PM, aakarsh1997 <aakarsh1...@gmail.com> > wrote: > >> Hi, >> >> I propose the inclusion of the node/io EventEmitter class[1] in core >> targeting ES7. >> >> Reasoning: >> The .on/.emit model is very popular[2] in the ECMAScript land, and it >> suits the language a lot. We use events pretty much everywhere in the JS >> land. >> It makes sense for the standard EventEmitter class used commonly to be >> included in core. With ES6 classes, userland code classes extending[3] the >> EventEmitter class would be pretty common and useful even in environments >> like browsers. >> >> Notes: >> I think the `.once` method from the node/io EventEmitter class _could_ be >> left out from standard implementation mainly because we would rather use >> Promises there. Although it would also make sense to keep it in for further >> compatibility. >> >> >> [1] https://iojs.org/api/events.html >> [2] >> https://github.com/search?l=JavaScript&q=eventemitter&ref=opensearch&type=Code >> [3] >> https://github.com/search?p=2&q=extends+eventemitter&ref=searchresults&type=Code&utf8=%E2%9C%93 >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
