Resending to v8-users@. 2015-09-09 17:31 GMT+09:00 Yuki Shiino <[email protected]>:
> I'm sorry that I misunderstood your question. Maybe I'm still > misunderstanding... Please correct me if any. > > There are (at least) two modes in the named property interceptor, masking > and non-masking. When masking mode, named properties have priority over > other regular members (attributes, etc.), so your named property handler is > invoked for every name look-up regardless of whether it's named property or > regular member. > > When non-masking mode (Web IDL spec requires the non-masking mode), > regular members have priority over named properties. The named property > handler is invoked only when the name does not match with any member of the > object or any member on the prototype chain. The named property handler is > invoked only when nothing is found. > > You can set v8::PropertyHandlerFlags::kNonMasking flag into > v8::NamedPropertyHandlerConfiguration when you install the named property > handler. We recently switched to this non-masking mode. > > > For another question why "window" object in Blink returns data-type > properties for attributes, that's a separate issue. That has nothing to do > with the named properties. We have several issues internally and we cannot > make Window's attributes accessor-type properties at the moment. But we're > actively working to fix the issues, and we'll make Window's attributes > accessor-type properties (hopefully in this year). > > Cheers, > Yuki Shiino > > > 2015-09-09 2:25 GMT+09:00 Domenic Denicola <[email protected]>: > >> [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]>: >> >> >> >> 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]> 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.
