I'd rather do something like:

Object.addEventListener(obj, "eventName", function(){});

I think this matches very closely the way you do property descriptors and
I'd love to see

var obj = {
on eventName() {}
}


On Wed, Jul 10, 2013 at 10:33 AM, David Bruant <bruant.d at gmail.com> wrote:

> 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 <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
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
- Matthew Robb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130710/93b2f225/attachment.html>

I'd rather do something like:

```js
Object.addEventListener(obj, "eventName", function(){});
```

I think this matches very closely the way you do property descriptors and
I'd love to see

```js
var obj = {
  on eventName() {}
}
```