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: > >> Hi, >> >> I have started a little experiment and I'd like to share it here. >> >> _Context_ >> We've been taught that objects are "attributes and methods". Consequently, >> object clients can inspect attributes (though these are most often private, >> but there can be constants) and actively call methods. >> However, a client cannot be told when the object changes states in a >> particular manner. In order for this to be possible, the object needs a >> publish/subscribe mecanism of some sort by using methods (.addEventListener >> and .dispatch for the DOM for instance). This mecanism is usually abstracted >> out. For the DOM, it is done by inheriting from EventTarget. >> >> One downside of using methods is that events are never really considered >> as part of the interface of the object. addEventListener and dispatch are, >> but there is no way, by inspecting the object to know which event this >> object "provides". Consequently, events are often poorly documented. For >> instance, I have never seen in a JavaDoc which events an object support and >> what their semantics are. >> Feature detection is even difficult for the case of the DOM. See >> http://www.w3.org/TR/DOM-**Level-3-Events/#feature-**detection<http://www.w3.org/TR/DOM-Level-3-Events/#feature-detection> >> >> So I wondered "what if events were part of an object and exposed as >> such?". What if an object, instead of being "attributes+methods" was >> "attributes+methods+events"? >> (as I learned later having that thought, what I'm describing is actually >> what some people call "component" in the software engineering literature) >> >> In this case, events would just be a native feature with potential support >> from a bunch of tooling from doc-generation software to code analysers. This >> idea is still new to me, but I think interpreters/compilers may be able to >> optimize better native events than one created with a hand-written library >> (where the engine cannot reverse-engineer the intention of an event >> mechanism). >> >> >> _The experiment_ >> So, I thought about JavaScript and the following line: >> ---- >> Object.defineProperty(o, 'e', {configurable: true, enumerable: true, >> event:true}); >> ---- >> The rest can be read at https://github.com/**DavidBruant/HarmonyProxyLab/ >> **tree/master/EventedObject<https://github.com/DavidBruant/HarmonyProxyLab/tree/master/EventedObject>(the >> code inside index.html shows how the API would work) >> >> Of course, the line above only works with newly created objects. >> I have not heavily tested this work and there are still open questions >> (like what would be a good use of the set trap?), but the index.html file >> works as I expect on Firefox 7. >> >> >> >> _Lesson learned during the experiment_ >> 1) first use of "finally" in JavaScript >> 2) >> https://bugzilla.mozilla.org/**show_bug.cgi?id=601379<https://bugzilla.mozilla.org/show_bug.cgi?id=601379>is >> a bit annoying, but I wrote a workaround for it by redefining >> Object.defineProperty. I hope this can be useful to others if you want to >> experiment new property descriptor attributes and test on Firefox until this >> bug is fixed. >> >> >> >> _Future work_ >> 1) see how to deal with inherited events >> 2) try, based on this kind of event to implement a DOM-like event >> mechanism with capture, bubble, stopPropagation, etc. to see whether these >> event properties can be used to easily implement such a thing. >> >> > 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. 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
