[re-sending with correct v8-users address this time] Sorry, I must not have explained correctly. I know that per Web IDL named properties are data properties. I am having trouble however figuring out how the V8 API will allow an object to have both a named property interceptor, and accessors, on the same object. When I add a named property interceptor to the object, it changes the object so that even when I define accessors on it, it now always reflects them as data properties.
My example, of window.frames, was meant to show this. Chrome reflects it as a data property, not an accessory property. Additionally, it is not a named property, so I should be able to redefine it. Currently in Chrome you cannot redefine it, probably because of the same named property interceptor issue. I was wondering what you planned to do to address this in Chrome, on a technical level, so that I could investigate similar fixes in Node.js. From: [email protected] [mailto:[email protected]] On Behalf Of Yuki Shiino Sent: Tuesday, September 8, 2015 03:02 To: Domenic Denicola <[email protected]> Cc: blink-dev <[email protected]>; Yuki Shiino <[email protected]> Subject: Re: [blink-dev] Re: Binding team snippet First of all, "named properties" are not DOM attributes. They're special and different from attributes. Attributes are defined as accessor-type properties by the spec, while named properties are defined as data-type properties by the spec. So it's expected that named properties are data-type properties. http://heycam.github.io/webidl/#named-properties-object-getownproperty You cannot do [[DefineOwnProperty]] for named properties. Exactly speaking, you can do, but it gets rejected. http://heycam.github.io/webidl/#named-properties-object-defineownproperty The problems you're facing seem no problem, they're the correct behaviors in terms of the Web IDL spec. Cheers, Yuki Shiino 2015-09-08 15:41 GMT+09:00 Domenic Denicola <[email protected]<mailto:[email protected]>>: On Tuesday, September 8, 2015 at 2:37:12 AM UTC-4, Kentaro Hara wrote: Has there been any effort yet to move the window attributes to be getters instead of data properties? I remember hearing this was planned but wasn't sure if you'd started yet. That is exactly the goal of all the work yukishiino@ has been doing :) We still need a substantial amount of work to get Window's members right but are planning to fix it by the end of Q4. See yukishiino@'s slide (https://docs.google.com/presentation/d/18Ap_EKEBu7nzDrlFM7FbCR4EgrNd3ryLabJUh-YvEwM/edit#slide=id.g2480feb0_1_0) for more context. Right, thanks! yukishiino@, do you have any thoughts in particular about the issue with V8's named property interceptor APIs only allowing data descriptors? Do you plan to change V8, or is there a different solution that I am missing? On Tue, Sep 8, 2015 at 3:29 PM, Domenic Denicola <[email protected]<mailto:[email protected]>> wrote: Has there been any effort yet to move the window attributes to be getters instead of data properties? I remember hearing this was planned but wasn't sure if you'd started yet. The reason I ask is that I am actually running in to very similar problems with Node.js<https://github.com/nodejs/node/issues/2734>. We have created "window like" objects using V8's SetNamedPropertyHandler and are noticing that all the accessor properties we define on this global object are now being exposed as data properties when you do `Object.getOwnPropertyDescriptor(globalProxy, "prop")`. `Object.defineProperty` does not work well on them either, just like in Chrome: Object.defineProperty(window, "frames", { get() { return 5; } }) will not change the result of Object.getOwnProperty(window, "frames"). So I was wondering if you'd started investigating fixes to this. Happy to take this offline or to v8-users if you think that would be more appropriate. On Sunday, September 6, 2015 at 8:35:26 PM UTC-4, Kentaro Hara wrote: Hi (yukishiino) Made the default receiver of callback functions "undefined". See this CL for more details: https://codereview.chromium.org/1301423004/. (yukishiino) Trying to move Window's methods from a prototype chain to an instance object (Note: Methods in [Global] objects need to be defined on an instance object, not a prototype chain). However, yukishiino@ hit a complex issue around Window.toString(). We decided to skip Window.toString() at the moment. -- Kentaro Hara, Tokyo, Japan -- Kentaro Hara, Tokyo, Japan -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
