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? jjb > > David > ______________________________**_________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
