bindings: Consider merging [SaveSameObject] and [SameObject] |
|||
Issue description(Spun off https://chromium-review.googlesource.com/c/chromium/src/+/689614) Right now, the bindings layer supports two related extended attributes: * [SameObject], which comes from WebIDL itself. As the spec says, "if the [SameObject] extended attribute appears on a read only attribute, then it indicates that when getting the value of the attribute on a given object, the same value must always be returned". * [SaveSameObject] is Blink-specific and caches the object returned by an attribute getter so that the getter is actually only called once. Right now, the [SameObject] extended attribute on its own does not do anything at all. I lack the historical context to understand why the two extended attributes are handled separately (even after looking at bug 462913 ). I wonder if we could just merge [SaveSameObject] into [SameObject] and make the former's behavior the default when one adds the [SameObject] extended attribute to a readonly attribute declaration. Read-only attribute declarations are also affected by our binding's layer |is_keep_alive_for_gc| work: in this case, should we prefer [SameObject]'s behavior over is_keep_alive_for_gc's? Is the caching currently done by [SaveSameObject] enough to prevent these objects from being GC'ed by V8?
,
Sep 28 2017
I don't exactly remember details, but I remember that I first tried to introduce [SameObject] with a feature of [SaveSameObject] plus [DontSaveSameObject] to support exceptional cases. However, some people preferred [SameObject] + [SaveSameObject] to [SameObject] + [DontSaveSameObject]. For private properties, I personally think that we should support mappings of (const char* => v8::Private) per isolate. Given the same key string, the mappings always return the same private property key. This is useful for not only [SameObject], but also other many use cases such as keep_alive_gc, cached accessors, etc. V8PerIsolate can hold such mappings.
,
Aug 1
,
Nov 30
|
|||
►
Sign in to add a comment |
|||
Comment 1 by raphael....@intel.com
, Sep 28 2017