events: prefix events to prevent breaking on known object properties

[3rd-Eden]

In the EventEmitter the events are stored in an plain Object instance. The event names that you use are added directly as property on the object so when you event names such as __proto__ it will break. One solution is to prefix the keys with a char such as ~.

Example case:

var EventEmitter = require('events').EventEmitter;
var e = new EventEmitter();

e.on('__proto__', function (bar) {
  console.log('foo', bar);
});
e.emit('__proto__', 1);

Willing to create pull request if bug requires fixing ;)

[cjihrig]

We just solved a similar problem with console timer labels. We ended up going with a Map, but Object.create(null) worked equally as well.

[Fishrock123]

Sounds like a spot to use Map. (Assuming it has decent perf)

[3rd-Eden]

I don't think that the performance of Map and Weakmap are better than Object.create(null)

[meandmycode]

According to this micro-benchmark (yep) you could expect map to be twice as slow:

http://jsperf.com/map-vs-object-as-hashes/14

Hash access may well not be the/a performance bottleneck in events though.

[petkaantonov]

@meandmycode You are comparing linear array to hash map.. you need to either use string keys or very sparse numeric indices to force the object into a dictionary mode.

Secondly the comparison is not fair unless you also factor in the cost of checking if a key is "__proto__".

So when using an object as a true string hash map (arbitrary string is supported, including proto) vs using Map, the speed is not surprisingly very much equal http://jsperf.com/map-vs-object-as-hashes/24

[cjihrig]

One thing to note is that the current version of v8 hasn't required explicit checking for __proto__.

[cjihrig]

Also, @bnoordhuis just pointed out on another issue that Object.create(null) is 15-30x slower than an object literal. I don't think it's worth it in this case.

[Trott]

I opened pull request to add a test for this to known_issues: #5649