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
andrea.giammar...@gmail.com 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
andrea.giammar...@gmail.com 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
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=JavaScriptq=eventemitterref=opensearchtype=Code
[3]
https://github.com/search?p=2q=extends+eventemitterref=searchresultstype=Codeutf8=%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
