> 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.
I don't think that Node.js is a relevant example here. Events are only exposed on instances (or subclasses) of EventEmitter. This happens to include a lot of the core objects, but it is nonetheless implemented via the [[Prototype]] and object-level properties (rather than anything resembling a MOP). I'm less familiar with FirefoxOS WebAPIs, but the same appears to be true here as well, unless I'm missing something. On Wed, Jul 10, 2013 at 1:33 PM, David Bruant <bruan...@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@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
