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

David Bruant bruant at enseirb-matmeca.fr
Tue Mar 15 18:43:43 PDT 2011


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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110316/c4f9c2cd/attachment-0001.html>

More information about the es-discuss mailing list