396265 - Want JSCLASS_NEW_ENUMERATE_GETS_START

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

> so if I understand correctly, it's impossible to use the start thing with
> newresolve while at the same time having sane enumeration behavior
> This seems like an API shortcoming to me, frankly
[skip some stuff]

> brendan: say I have the following prototype chain: XULElement -> Binding1 ->
  Binding2 -> Object
> brendan: The issue is that as XBL is currently set up, the Binding1 and
> Binding2 objects will be the same for all elements that have this binding
  attached to them
> so if I have two nodes that have the same binding attached, the proto chain
  only differs in the leaf
> brendan: Now the way XBL fields work is that they are evaluated once, with
  the resulting value being the field value
> brendan: since the field value may differ from element to element, they need
  to get defined as props on the XULElement in that chain
> brendan: My patch is making field definition lazy
<brendan> bz: but storing field value where?
> brendan: so instead of doing a bunch of string evals and JS_Define*Property
  calls at binding attachment time, I do the string eval in the Binding1 and
  Binding2 newresolve hooks
> brendan: and still call JS_Define*Property on XULElement
<brendan> using JSCLASS_NEW_RESOLVE_GETS_START
> brendan: the problem is what happens when someone enumerates properties on
  the XULElement
> brendan: without my patch, all the fields are eagerly defined, so they're
  all there
> brendan: with my patch, they're not
> brendan: unless I can somehow catch the enumeration start and define them
  all at that point
<brendan> but you aren't writing enumerate hooks for XULElement et al.
> brendan: right
> brendan: not if I can avoid it
<brendan> you want JSCLASS_NEW_ENUMERATE_GETS_START
<brendan> file a bug