[Harmony proxies] Opinion on the open issue (How to deal with inconsistent data returned by handler traps?)

Tom Van Cutsem tomvc.be at gmail.com
Wed Mar 16 02:25:00 PDT 2011


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: <
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.


2011/3/16 David Bruant <bruant at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110316/7ee3e21d/attachment-0001.html>

More information about the es-discuss mailing list