932409 - Bindings.conf should explain what it means when an entry is a list

Status: RESOLVED DUPLICATE of bug 932505

(Core :: DOM: Core & HTML, defect)

Description

[Andrew McCreight [:mccr8]]

Apparently if the entry for an interface is a list, then the first element is for the main thread, and the second is for workers.

Comment 1

[Andrew McCreight [:mccr8]]

I'll have to dig around in the code that does this a bit, but it seems to me that if in these lists the second element is implicitly workers-only, we should just make it implicitly set workers=True, rather than having to add that to the Bindings.conf, in the spirit of minimality.  Of course, we'd have to update the documentation for "workers" for that change.

Comment 2

[Andrew McCreight [:mccr8]]

I looked at the code a bit, and the actual bindings generation code does not really correspond to the description in comment 0.  What happens is, if you have a list, just generate everything in the list no matter what.  The one exception seems to be that if the list has a single item in it, and it has 'workers'=True, then automatically add an additional empty bindings conf thing, so we get a main thread binding thing, too.

If you have a list with a single dictionary in it, like [{whatever}], that's exactly the same as {whatever}, as long as you don't define 'workers'=True, which seems somewhat silly.  DelayNode, ImageData, and PannerNode all do that.

More troublingly, it is okay to have bogus things like:
  'Event': [{'nativeType': 'nsDOMEvent',}, {'nativeType': 'nsDOMEvent',}, {'nativeType': 'nsDOMEvent',}]

and it will just generate bogus C++ code, because we end up defining the same enum multiple times.  I'll file a separate bug on adding a little bit of sanity checking for Bindings.conf.