I'm in favour of this standard class approach.

I just hope that when discussing this people would also entertain a
non-string event type.

emitter.addListener( MY_EVENTS.PERMISSION_UPDATE, callback );

So in a modern IDE you could click on MY_EVENTS.PERMISSION_UPDATE and
it would display the object which could contain the arguments the
callback is provided with and a place to document the event.
It might also improve minifying/refactoring and searching for
occurrences of the event much easier then if it where a simple string.


On Thu, Jul 11, 2013 at 2:37 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
>
>
>
> On Wed, Jul 10, 2013 at 9:31 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
>>
>> On Wed, Jul 10, 2013 at 6:16 PM, Rick Waldron <waldron.rick at gmail.com>
>> wrote:
>>>
>>>
>>> I absolutely stand by championing such a standard module.
>>>
>>
>> then I stop here waiting for other opinions about championing an Emitter
>> mixin/module/constructor in core.
>>
>> best regards
>>
>
> I feel like we've made progress https://github.com/tc39/agendas/pull/6
>
> Rick
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

I'm in favour of this standard class approach.

I just hope that when discussing this people would also entertain a
non-string event type.

```js
emitter.addListener( MY_EVENTS.PERMISSION_UPDATE, callback );
```

So in a modern IDE you could click on `MY_EVENTS.PERMISSION_UPDATE` and
it would display the object which could contain the arguments the
callback is provided with and a place to document the event.
It might also improve minifying/refactoring and searching for
occurrences of the event much easier then if it where a simple string.