My favorites | Sign in
Project Home Downloads Wiki Issues Source Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 1482: It is not possible to configure properties with getters and setters with an ObjectTemplate
10 people starred this issue and may be notified of changes. Back to list
Reported by, Jun 19, 2011
ObjectTemplate::SetAccessor always produce a property with a descriptor that has 'value' (as returned by the AccessorGetter). It should be possible to produce a property that has a descriptor with 'get' and 'set' instead. Perhaps a SetAccessor overload that accepted FunctionTemplates instead of AccessorGetter/AccessorSetter would be appropriate.

The WebKit V8 bindings need to be able to configure an ObjectTemplate that expose a getter and setter, per the Web IDL spec. (See WebKit bug 49739.)
Jun 20, 2011
Project Member #1
I don't think this would involve an API change. What you are requesting is that accessor properties be exposed as functions to JavaScript via getOwnPropertyDescriptor, right? The wrapping of the accessor in a javascript function should probably happen internally in the engine without an API change.

This will have serious consequences for all embedders. It means that you can move an accessor to another object type. That is currently not possible and therefore accessors (at least in Chromium) rely on the fact that the info.Holder() object in the callback always has a certain type. This will lead to nasty crash bugs. Therefore, I don't think we can make this change before at least the Chromium bindings have been updated to be able to deal with this and the performance impact of that has been measured.
Jun 20, 2011
Project Member #2
By the way, the accessors in Chromium all have to be updated if these attributes are moved to the prototype chain as accessors as well. I would be interested in the DOM performance impact of such a change.

For my education, is there a document with the rationale for wanting to move attributes that conceptually belong on instances to the prototype chain?
Jul 4, 2011
Yes, you could also change the existing API to wrap getter and setter callbacks and expose them as JavaScript functions; understood that implementers could no longer being able to rely on the receiver of calls to the getter/setter being the  same type of object as originally configured (so you could make this new API to avoid that; embedders that wanted the new semantics could opt in to them.)

My gut feeling is that it would be nice to sometimes be able to have the option of playing the current "trick" (for example for backwards compatibility, or for lazy properties still exposed with 'value') but I don’t have concrete cases in Chrome that need this, however I haven’t looked for any. Should I investigate?

The status of WebKit bug 49739 is that we need to prototype the change to measure the performance impact. (Incidentally, both JSC and V8 have evolved with exactly the same behavior.) So I could also prototype the change in V8, with some guidance, or someone else could prototype it and I can patch it locally for the larger WebKit prototype.

If you have intuition about the performance implications, and whether there’s anything the VM can do to ameliorate it, I would love to hear about it.

The broad rationale for this change in Web IDL is that the DOM should look and feel like any other JavaScript object. The specific kinds of use cases this change enables are when people want to hook a getter or setter to customize the behavior of an object or element kind. That is not possible today, because even if you can replace the built-in accessor, you lose the original definition and can’t thunk to it.
Sep 6, 2011
Ping on this. It's blocking Web Components from working naturally.
Jan 18, 2012
i  just  want  a  computer  not  a  school 
Aug 14, 2013
Project Member #6
(No comment was entered for this change.)
Status: Accepted
Labels: Type-FeatureRequest
Aug 16, 2013
Project Member #7
(No comment was entered for this change.)
Sign in to add a comment

Powered by Google Project Hosting