776383 - Generate code automatically at least for normal WrapObject implementations

Status: NEW

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

Description

[Olli Pettay [:smaug][[e-mail]]]

It is über-ugly to require even simple DOM classes to have WrapObject which is all about
JSAPI. At least in certain cases the code could be automatically generated to call
dom::FooBarBindings::wrap()

Comment 1

[Boris Zbarsky [:bzbarsky]]

You'd still need to _declare_ WrapObject in the classes, right?  But the impl could be autogenerated...

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I think even the declaration shouldn't be needed.

Comment 3

[Boris Zbarsky [:bzbarsky]]

How could it not be needed?  The class needs to declare this (virtual) function so wrapping it via XPConnect (e.g. as a return value from an old-binding class method) works.

Unless you want to do this only for classes that are never wrapped via XPConnect (as in, _only_ used in WebIDL)?

Comment 4

[Peter Van der Beken [:peterv]]

(In reply to Olli Pettay [:smaug] from comment #2)
> I think even the declaration shouldn't be needed.

Can you please explain how to do this? I don't see it. How do you determine which binding to use? There's no direct mapping from C++ class to binding.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Maybe something like
template <class T > class Binding : nsWrapperCache
{
  virtual JSObject* WrapObject(JSContext* cx, JSObject* scope,
                               bool* triedToWrap)
  {
    return mozilla::dom::WrapObject<T>(cx, scope, triedToWrap);
  }
}

Specialized version of
template <class T> WrapObject(JSContext* cx, JSObject* scope,
                              bool* triedToWrap)
would be autogenerated for all the bindings where default WrapObject makes sense.

then 
template <class T> nsDOMEventTargetHelper : Binding<T>

And for example WebSocket
class WebSocket : nsDOMEventTargetHelper<WebSocket>, ...

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(Obviously I didn't try that approach, but I think something close to it might work.)

Comment 7

[Peter Van der Beken [:peterv]]

So if something inherits from WebSocket you need to templatize it? Not sure how that's much cleaner.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Hmm, yeah, that would be a problem :(

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

If we had spare bit in nsWrapperCache, we could use that to indicate that the value of mWrapperPtrBits is actually index to a binding table. But there isn't any spare bits :(

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

No, that would work only for the first wrap.

Ok, this is trickier than I thought originally :)
I still very much wish that there would be a way to implement JS exposed stuff without
JS API usage.

Comment 11

[Boris Zbarsky [:bzbarsky]]

For wrappercached things, we could maybe make that work.  Two notes:

1)  Wrappercached objects are at least two words in size, right?  Can we guarantee that they're bigger than that in practice?  Because with jemalloc all allocations that are larger than 8 bytes are at least 8-byte aligned.

2)  The finalizer could restore the correct pointer as needed.

Comment 12

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.