Hi, On the proxy proposal is an open issue. It starts with "How to deal with inconsistent data returned by handler traps?" (actually, the issue also applies to inputs since I can provide garbage as Object.defineProperty arguments). First of all, I think that there might be a false assumption in the question. It would be in the word "inconsistent". Inconsistent with what? From what I understand, the answer would be "with our current knowledge, use and understanding of objects". But should proxy be consistent with this?
The first sub-question is "what to do if the return value of getOwnPropertyNames or keys contains duplicate property names: silently filter them out, leave them, or throw?". So I have started to wonder "why would Object.getOwnPropertyNames return duplicates?". So I have thought of a case where objects, for the same key would have not one, but several values. Long story short, with Object.defineProperty, you add a value, with get/set, you play with the last value and with delete, you delete the last value. I have implemented it and invite you to run http://davidbruant.github.com/PropStackObjects/ on Firefox4 and look at the source code https://github.com/DavidBruant/PropStackObjects/blob/gh-pages/index.html With this "several values per property name", one could expect to see as many duplicates of the same key than the number of values of this key on the object after a Object.getOwnPropertyNames. I have implemented the thing, but as you will notice on Firebug/WebConsole, since there is some data massaging on the output of the trap, duplicate keys disappear. My point is that it might be too restrictive to consider proxies as things "that behave like objects with some differencies". The ability to have functions (arbitrary code) to define a behavior potentially offers library authors the potential to consider objects differently than we used to. In my example, I am breaking the idea that a property name is bound to at most a unique value. In my example, it's a stack. And through the handler code, I am offering the guarantee that get and set only act on the last value. The way I see it, proxies offer the possibility of a dialog between library authors and library users and for this dialog, there is no need to learn a new language. This dialog happens with the "Object vocabulary" (with library author-defined semantics). And in my opinion, it would be a mistake to constraint this dialog to what we know for current objects. While implementing this first example, I have realized that the property descriptor was somewhat inappropriate, because I didn't want, for instance, a non-configurable value that could "block" the stack. Actually, besides the value, nothing really mattered to me. And then I thought that through property descriptor, I could carry more meaning than with the current attributes. Since the property descriptor is an object (and that was a genius idea!) I could add an 'index' property attribute in my descriptor to explicitely tell where in the stack I want the property to be added to. My property descriptors would look like {value:"myValue", index:3}. Hence, second experiment : http://davidbruant.github.com/PropStackObjects/index2.html code: https://github.com/DavidBruant/PropStackObjects/blob/gh-pages/index2.html Unfortunately, currently, on FF4, the property descriptor is rewritten, but with my comments on the code, you can see what results I would expect. But the potential of having my library-specific property descriptor format is here. During these experiments, imposed data massaging has been frustated, because I the dialog I was trying to instore between the library code and the calling code was restricted by the engine. It would be the same with throwing. I know that what I am proposing is a break of the usual contract between what objects are and what people object to be. But I do not see why I, as a library writer couldn't decide to write another contract with my library users, one where I would be allowed to duplicate keys in Object.getOwnPropertyNames or one where I decide of the format and semantics of a property descriptor and so on. To answer the concern of derived traps default behavior expecting some format: if I'm planning on "creating a new contract", I would override them and make sure I respect the invariant and properties my library users expect in all circumstances. I think that through proxies, with "uncontrolled trapping", it is likely that we see new usages and new forms of objects (Array could have emerged from that: https://github.com/DavidBruant/ProxyArray). Some of these new forms could even be included to ECMAScript one day, why not? If data validation was expected anyway for security or debugging purposes, maybe that another type of proxy could be invented in which each trap call is controlled (input and output). Maybe that this could be done through Proxy.safeCreate() or something like that. It would return a "safe proxy". Validation/normalizing methods could also be provided by Proxy in order to help implementors validate their inputs. Of course, all said here is to be discussed, so let's discuss. David
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
