Le 05/04/2011 10:22, Tom Van Cutsem a écrit : > Hi, > >> I'd like to remind that if Object.getPropertyDescriptorisn't >> a native function with a native underlying internal method, >> but a monkey patch, it will not call a proxy trap (maybe this >> should be addressed?). >> >> >> There's a Harmony proposal that proposes adding >> Object.getPropertyDescriptor as a new built-in on Object for >> precisely this >> reason: >> <http://wiki.ecmascript.org/doku.php?id=harmony:extended_object_api> > I agree. > The point I wanted to see addressed is when ES engines only > partially natively implement the Object introspection API. > Currently, Safari 5 doesn't implement > preventExtension/seal/freeze. No browser implement > getPropertyDescriptor and getPropertyNames (so > Object.getPropertyDescriptor wouldn't be trapped if monkey-patched). > If all browsers implement proxies now, the same code will reveal > inconsistencies if browsers have different stage of Object.* > implementation. > Same thing if new traps are created afterward. It's very unlikely > that all browser will implement the relevant Object.* method at > the same time. > Maybe we should investigate something like Proxy.trap(o, name, > arguments). Example: > ---- > if(typeof Object.getPropertyDescriptor != "function"){ > Object.getPropertyDescriptor = function(o){ > if(Proxy.isProxy(o)){ // There is a need to be able to > discriminate > return Proxy.trap(o, "getPropertyDescriptor"); // call the > trap manually, because the native code cannot do it. > /* For seal/freeze, the trap name has nothing to do with the > method name and no 1:1 mapping can be done, hence the string > argument */ > } > else{ > // code for regular object > } > }; > } > ---- > This has downsides and as always, I'm not going to fight for this > particular syntax, but I think that there is a need for a > mechanism for developers to compensate browsers uneven > implementations. > In a world where all browsers would all move at the same pace and > older browsers market share were dropping as soon as a new version > was showing up, we wouldn't need such a mechanism, but I don't > think we should assume living in such a world. > > > Is it really that big an issue? > > Considering Object.getPropertyDescriptor, if a shim defines it in > terms of a recursive prototype-chain walk + > Object.getOwnPropertyDescriptor, I would surmise that this leads to > correct behavior if the proxy is well-behaved (i.e. the > prototype-chain it emulates is consistent with > |Object.getPrototypeOf(proxy)| ). I see two things when trapping: the trap call (with side effects) and the return value. I agree with you on the return value. But if the proxy doesn't trap it also means that there is no side effect (logging, forwarding, visitor/decorator pattern...). That's a bigger issue in my opinion.
> If a browser does not support Object.freeze, seal or > preventExtensions, it likely does not support fixing proxies either. > Calling the "fix()" trap explicitly via Proxy.trap would still not > lead to the expected behavior. You are right. Maybe it could be written somewhere that Proxy should only be implemented in an ES5-compliant environment (+ maybe other dependencies). Cheers, David > Cheers, > Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
