Proposal to add EventEmitter to core [ES7]

aakarsh1997 aakarsh1997 at gmail.com
Mon Jun 1 12:17:41 UTC 2015


> 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.giammarchi at 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.giammarchi at 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.giammarchi at 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 <aakarsh1997 at 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 at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150601/db400372/attachment.html>


More information about the es-discuss mailing list