This sounds like it is going to be a useful experiment. It's closely related to why I didn't the analysis that is available at http://www.wirfs-brock.com/allen/things/es5-technial-notes-and-resources. The ES5 array spec. is written based upon the ubderstanding that [[DefineOwnProperty]] is a "fundamental" operation that all other "internal methods" and operations use to actually store property values. Since these internal methods provide the linkage between the surface syntax/semantics of the language and the internal object semantics it is going to be important that proxy traps provide an identical mapping.
I think in the end we will probably have to refactor both the current "internal methods" and the current traps but I think we can arrive at a design works. Allen On Jan 28, 2011, at 2:56 PM, David Bruant wrote: > Hi, > > 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 15.4.5.1 > ([[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: > http://wiki.ecmascript.org/doku.php?id=harmony:proxy_defaulthandler). > 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 > traps: > 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! > > David > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
