Hi, I recently filed a bug on Firefox [1] regarding the fact that i find the prototype chain of event objects to be messy (half of the problem is Firefox specific, the other half is standard as per WebIDL). In this page [2], click anywhere to see a click event prototype chain (top-left object is the own layer, then, in reading order, its prototype, then its prototype, etc. Initial screen is the global object).
On the prototype chain are all event properties (type, target, eventPhase, etc.) which all appear on the prototype chain and as getter/setter pairs as per WebIDL [3] [4]. In the long term, I wish my vizualisation tool to be used live to take snapshots of an object (and allow to visually compare 2 states of an object at 2 different times, for instance), so I made the choice to not call getters in order to avoid unexpected side effects. This goes with the constraint that in the very case of WebIDL, i can't retrieve the type of the different properties nor the value. Unlike in Chrome which does not follow WebIDL, but provides a better visualization (in my opinion). The discussion in the bug revealed that the WebIDL choice is made in order to allow composition: "Making the properties live on the prototype allows hooking them on all objects of a given type, which is something web developers commonly want.". Consequently, the properties must remain in the prototype object representing each interface. Given this constraint, it becomes compulsory in pure ECMAScript 5.1 for properties to be setter/getter pairs in order to return a value per object inheriting from the interface-prototype-object (thanks to the |this| binding). In an ES5.1 + proxies world, it could be imagined that interface-prototype-object could be proxies returning a different /data/ property descriptor based on the "requesting" object. Both responding to the WebIDL constraint and providing the ability to automatically retrieve value and type. Unfortunatly, there is currently no way to have per-inheriting object behavior as there is no way to pass the inheriting object. There was with the "receiver" argument of get and set traps but it's on its way to be killed. Anyway, it wouldn't be enough. I think that all proto-climbing read traps (getPropertyDescriptor, getPropertyNames, has, get, enumerate) should have access to the requesting/receiver object. It's more than necessary for the use case that i raise, but sounds consistent to me. In accessor properties the receiver object is provided as a |this| binding. This is not possible in proxy traps as |this| is used to denote the handler object. Consequently, an additional argument seems to be the way to go. David [1] https://bugzilla.mozilla.org/show_bug.cgi?id=684696 [2] http://davidbruant.github.com/ObjectViz/ [3] http://www.w3.org/TR/WebIDL/#interface-prototype-object [4] http://www.w3.org/TR/WebIDL/#es-attributes _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
