David Bruant (2013-07-10T18:19:35.000Z)
Le 10/07/2013 19:57, Jeremy Martin a écrit :
> > 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.
That's not my point. I was explaining that people consider events as 
part of the object interface (regardless of how the event system is 
implemented).

Currently, to express events in JavaScript, one has to go through a 
specific [[Prototype]] or extending with a mixin which feels awkward to 
me. Do we need a mixin to add properties to an object? or a specific 
[[Prototype]] to add methods?

In the DOM, having to inherit from EventTarget creates this weird 
situation where events can't be part of WebIDL. It is even rarely 
possible to be able to list all events supported by a given object 
(which in turns makes documenting event quite of a nightmare). Supported 
events have to be aliased via on* properties to be feature-detectable.
This madness really has to stop. We need first class events (and I'm 
praying for a way to retrofit them into the DOM if possible)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130710/46604614/attachment.html>
domenic at domenicdenicola.com (2013-07-16T14:24:27.389Z)
Le 10/07/2013 19:57, Jeremy Martin a écrit :
> 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.

That's not my point. I was explaining that people consider events as 
part of the object interface (regardless of how the event system is 
implemented).

Currently, to express events in JavaScript, one has to go through a 
specific [[Prototype]] or extending with a mixin which feels awkward to 
me. Do we need a mixin to add properties to an object? or a specific 
[[Prototype]] to add methods?

In the DOM, having to inherit from EventTarget creates this weird 
situation where events can't be part of WebIDL. It is even rarely 
possible to be able to list all events supported by a given object 
(which in turns makes documenting event quite of a nightmare). Supported 
events have to be aliased via on* properties to be feature-detectable.
This madness really has to stop. We need first class events (and I'm 
praying for a way to retrofit them into the DOM if possible)