Le 10/07/2013 16:53, Andrea Giammarchi a écrit :
> Just a humble attempt to propose some addiction to the 
> `Object.prototype` I already know many will kill me for even trying to 
> ...
>
> **tl;dr** - everything proposed can be already tested through this 
> utility called 
> [eddy.js](https://github.com/WebReflection/eddy#event-driven-js)
>
> ### Event Target All The Things
> One of the most widely adopted API in JavaScript world is based on a 
> combination of these methods:
>
>  * `.on(type, handler[, capture])` used as equivalent of 
> `addEventListener` in the DOM namespace, also used in every library 
> that would like to be event driven. Smart enough to avoid duplicated 
> entries for the same handler over the same event type.
>  * `.once(type, handler[, capture])` used to simplify `.on()` within 
> an `.off()` at the top of the invocation to ensure a "one shot only" event
>  * `.off(type, handler[, capture])` to remove a previously set event 
> handler or silently failif not present
>  * `.emit(type[, arg1][, argN])` directly from node.js world where 
> almost every object is an EventTarget and EventEmitter anyhow since 
> it's needed and has been proven it's a highly appreciated/welcome 
> approach.
>  * `.trigger(type[, data])` similar to `.emit()` except it 
> triggers/fires an event object with some extra method such 
> `evt.stopImmediatePropagation()` or others DOM related when the event 
> comes from DOM
>
> The proposed implementation lazily assign internal listeners event 
> handlers only once these methods are invoked for the very first time.
>
> This makes every object
... inheriting from Object.prototype...

> able to be promoted at runtime as event emitter:
> ```javascript
> var o = {};
> // o is just an object
>
> o.on('event-name', console.log.bind(console));
> // now o has internals able to work with handlers
>
> o.trigger('event-name');
> // will log an Event object
> ```

I believe events should be part of the object MOP interface (regardless 
of the [[Prototype]] value). Events are already part of the interface of 
objects as people use them:
* in Node.js, events are documented at the same level than properties 
and methods.
* In new FirefoxOS WebAPIs, pretty much every new object inherits from 
EventTarget.

Also, Object properties now have their events (Object.observe), 
following DOM mutation-related events (DOM Observers API). It won't take 
long before someone asks for mutation events in ES6 Maps and Sets...

Anyway, I agree with the intent, but I would put the tool at a 
lower-level if given the choice.

David

I believe events should be part of the object MOP interface (regardless 
of the [[Prototype]] value). Events are already part of the interface of 
objects as people use them:

* in Node.js, events are documented at the same level than properties 
and methods.
* In new FirefoxOS WebAPIs, pretty much every new object inherits from 
EventTarget.

Also, Object properties now have their events (Object.observe), 
following DOM mutation-related events (DOM Observers API). It won't take 
long before someone asks for mutation events in ES6 Maps and Sets...

Anyway, I agree with the intent, but I would put the tool at a 
lower-level if given the choice.