Le 10/07/2013 20:00, Matthew Robb a écrit :
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() {}
}
That's the spirit. I don't care for particular syntax, but that's what I
had in mind too.
A while ago, I started a library to have first-class events as object
properties in specialized proxies [1]. It has some inherent limitations
but is a start in one direction.
David
[1]
https://github.com/DavidBruant/HarmonyProxyLab/tree/EventedObjectsOnDirectProxies/EventedObject
On Wed, Jul 10, 2013 at 10:33 AM, David Bruant <[email protected]
<mailto:[email protected]>> 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)
### 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
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
--
- Matthew Robb
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
