On Wed, Oct 12, 2011 at 9: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. > > ISTM a lot of this is already pretty common, and almost a de facto standard ducktype using the `on` method (e.g. dojo, node, etc.). This pattern is common enough that maybe it merits some kind of de jure support, but obviously it'd be tough to do it using the string `on` as a method. A private name combined with the module system could be perfect for this though, and would enable stratified ducktyping: // get private name `on` from some made up @events module import on from @events // turn some `foo` obj into an event emitter foo[on] = {} // add a `change` handler foo[on].change = function(handler) { /* ... */ } So in this way "component" objects can be reflected on at runtime, and if done in a controlled fashion could even be extracted out by doc tools automatically. The only de jure aspect to this would be where to put this particular private name in the grand es-next "ontology". And maybe we don't even need that. There are other ducktypes that could really stand to gain from this treatment -- one that comes to mind is the Promises/A `then` method. For various reasons, largely around the possibility of sandboxing, `instanceof` is insufficient as a universal branding for promises. The ducktyped `then` approach overcomes this obstacle, and opens the doors to interoperability between any number of promise producers and consumers, as we're witnessing now. But it's still a hazard -- one that private names could fix. But unless we can agree where to put that private name we'd be taking a step back WRT interop. And the same could be said of the ducktyped `on` I suggested above. I'm curious what folks think about this kind of approach? It's the reason I'm such a private name fanboy -- I think it's a pretty interesting opportunity to push library interop forward.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
