David, This open issue is indeed one that merits further discussion here.
Some thoughts and comments: * I think we did come to an agreement that custom property attributes were seen as very useful for communicating new kinds of meta-data about objects, and that they ought to be preserved. See also this bug: < https://bugzilla.mozilla.org/show_bug.cgi?id=601379> That would solve one of the issues you raise. * The place where argument/return value validation is most critical is where fundamental traps are called by the runtime itself, not by client code, because of a missing derived trap. The question here is: how should the default implementation of a derived trap deal with inconsistent data returned by the fundamental trap on which it relies? * If proxy handlers are allowed to free-wheel and return whatever they like, this will no doubt break some invariants of client code. I don't think something like Proxy.safeCreate is a particularly good idea, since: a) it further increases the complexity of an already complex API b) it puts the responsibility for ensuring safety on the wrong party: if safety is required, it's not a good idea to rely on library authors to use Proxy.safeCreate instead of Proxy.create. The library author can always "forget" (unintentionally or intentionally). I believe Allen raised the idea at one of the last TC39 meetings that a safe subset could replace Proxy.create, Object.keys, etc. with safe variants that check for consistency. I recall that MarkM objected on the grounds that this approach could be prohibitively expensive for some checks, such as filtering out duplicates. Cheers, Tom 2011/3/16 David Bruant <bru...@enseirb-matmeca.fr> > 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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
