> I'd rather migrate to a new standard than bring EventEmitter If we can get an EventEmitter more suitable than the one node.js has to offer, I am all for it.
On Mon, Jun 1, 2015 at 3:24 PM Andrea Giammarchi < [email protected]> wrote: > Dan Peddle wrote me without replying to all about the limit that is > configurable ... yes, I know that, but having no limit on core or a > configurable limit different from 10 would make again the new thing > inconsistent with current EventEmitter in node. > > Again, I'd rather migrate to a new standard than bring EventEmitter as it > is from node.js world to core ES.next, and also using traits. > > Regards > > On Mon, Jun 1, 2015 at 11:01 AM, Andrea Giammarchi < > [email protected]> wrote: > >> 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 < >> [email protected]> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
