On Wed, Oct 12, 2011 at 9:50 AM, Dean Landolt <[email protected]> wrote:
> > > On Wed, Oct 12, 2011 at 10:42 AM, John J Barton < > [email protected]> wrote: > >> >> >> On Wed, Oct 12, 2011 at 6:38 AM, David Bruant <[email protected]> wrote: >> >>> >>> >> Rather than properties, how about modeling events with promises or await? >> > > > To my mind, a promise is to an event as a scalar is to a vector. > Ah, nice analogy. Let me just see if I understand. An observer of an object's 'event-api-thingy' expects a stream of calls, once for each occasion of the event. If the thingy were a promise, then the first occasion would consume it. The C# solution maps addEventListener(name, fnc) into +=() on the |event| object and removeEventListener into -=(). The |event| then is a function with a list attached; calling the function dispatches to the list. http://msdn.microsoft.com/en-us/library/aa645739%28v=vs.71%29.aspx > In the past I've experimented with modelling events as a kind of a lazy > array -- an object with a forEach method that takes a "handler" function and > returns a promise that eventually resolves to undefined (when the event > stream is over). It's certainly possible, but a little more awkward to > explain to a javascript dev than the run-of-the-mill event emitter pattern. > Is their any hope of solving the "GC" problem with events? By that I mean the tedious business of matching removeEventListener to every addEventListener. If I take an event-thingy from an object, then drop the reference, the remove is automatic: foo.observeBar = function(event) { // foo deals with bar's change }.magicHere( bar.changed); ... delete foo.observeBar; // remove event listener or foo gets deleted or goes out of scope etc. And to round out my random comment, take a look at MDV as well: http://code.google.com/p/mdv/ jjb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
