[ES Harmony Proxies] Feedback on implementing arrays with proxies

David Bruant bruant at enseirb-matmeca.fr
Fri Jan 28 14:56:13 PST 2011


I have decided to work on trying to (re-)implement native arrays with
proxies. All the code is here: https://github.com/DavidBruant/ProxyArray
and I'd like to provide some feedback.

* The approach
The basic idea was to:
- use a forwarding proxy
- change the defineProperty trap into an adapted version of ES5
([[DefineOwnProperty internal method of native array objects]])
- reimplement the constructor.

* First issue: the 'set' trap (and all derived traps)
The very first issue I've encounter was that setting a property on the
proxy was (obviously) forwarded on the target using the 'set' trap.
Consequently, my defineProperty was just bypassed.
It got me thinking of the forwarding proxy example (which is on its way
to being standardized:
Would it make sense to define a default forwarding proxy as a proxy "in
sync" with an object? This definition would deserve to be more
formalized, but the idea is that if you write:
var h = new Proxy.Handler(obj);
var p = Proxy.create(h, Object.getPrototypeOf(obj));
then your program cannot tell the difference between obj and p besides:
- if you do preventExtension/seal/freeze on the proxy (which fix it
proxy and break the inner link between obj and p).
- obj !== p

Based on that definition, we could have a stronger definition of derived
Derived trap are defined as ES code using fundamental traps in order to
respect the forwarding proxy definition. Before going any further, I'd
like to say that it's already the case :-) In my opinion, that was the
rational behind Mark Miller's "coherent behavior to fall back to" idea
of what should be derived or fundamental. Coherent with what? With what
we expect from native objects.
To solve my problem with proxyArrays, I got rid of all derived traps
definitions in the forwarding proxy code and it worked perfectly. It
could make sense to do exactly the same with the default proxy
forwarding handler, otherwise, people who just want to implement a
fundamental trap (like I did) will have to reimplement all derived traps
depending on the fundamental and it is very likely that their
reimplementation will be the derived trap default definition.

* getPropertyDescriptor
Since this function isn't implemented in FF4 and that there is no access
to the proxy object, it was impossible to reach the prototype.
"Fortunately", I knew that it had to be Array.prototype. I have
hardcoded the prototype chain walk. We have already discussed this issue
in previous e-mails.

I hope this feedback will be helpful.

Thanks for reading!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110128/8c43f2cb/attachment.html>

More information about the es-discuss mailing list