Brian Di Palma (2013-07-13T09:18:39.000Z)
I didn't suggest that strings as event type would block anyone,
strings work fine.

I asked for some consideration to be given to also being able to use a
unique object as the type key.
I gave some reasons, copied below.

"
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.
"

None of which are critical but could be handy when dealing with larger
code bases and your event is simply called "click".

I'm not too wedded to the idea, but I can imagine that if you are
building applications with hundreds of packages and modules it might
be a safer/easier way to identify instances of your specific event
listeners.

On Thu, Jul 11, 2013 at 11:04 PM, Andrea Giammarchi
<andrea.giammarchi at gmail.com> wrote:
> trivial like ... 2 weak maps + a set for a single event ?
>
> ```javascript
> obj.on(evt, handler);
> ```
>
> .. internals ...
>
> ```javascript
> // wm as private internal generic WeakMap
> if (!wm.has(obj)) {
>   // creates related WeakMap
>   wm.set(obj, new WeakMap);
> }
> if (!wm.get(obj).has(evt)) {
>   wm.get(obj).set(evt, new Set);
> }
> wm.get(obj).get(evt).add(handler);
> ```
>
> I have the feeling it's very true in JS world nobody ever thinks about RAM
> and GC ^_^
>
> That said, it becomes over complicated for non concrete reason/use case if
> we have strings since AFAIK WeakMap does not accept strings as key.
>
> For all this time the event type as string has blocked like ... nobody ever
> ? I wonder again what's the benefit then to instantly over complicate an API
> at this stage instead of looking around what worked already for everyone.
>
> Maybe it's me not seeing the power of objects as events.
>
> br
>
>
>
> On Thu, Jul 11, 2013 at 2:32 PM, Rick Waldron <waldron.rick at gmail.com>
> wrote:
>>
>>
>>
>>
>> On Thu, Jul 11, 2013 at 4:45 PM, Andrea Giammarchi
>> <andrea.giammarchi at gmail.com> wrote:
>>>
>>> I would simplify saying that symbols can be used as well as strings ? I
>>> don't see any usefulness into using an object as event type and I think if
>>> we start olready over-engineered/complicated this will never see the light
>>> in any spec which is a lost/lost if you ask me
>>
>>
>> It's trivial if an Emitter uses something like [[MapData]] or
>> [[WeakMapData]] as it's internal data property for event storage.
>>
>>
>> Rick
>>
>
domenic at domenicdenicola.com (2013-07-16T14:27:11.605Z)
I didn't suggest that strings as event type would block anyone,
strings work fine.

I asked for some consideration to be given to also being able to use a
unique object as the type key.
I gave some reasons, copied below.

> 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.

None of which are critical but could be handy when dealing with larger
code bases and your event is simply called "click".

I'm not too wedded to the idea, but I can imagine that if you are
building applications with hundreds of packages and modules it might
be a safer/easier way to identify instances of your specific event
listeners.