Open Bug 776383 Opened 12 years ago Updated 2 years ago

Generate code automatically at least for normal WrapObject implementations


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





(Reporter: smaug, Unassigned)


(Blocks 1 open bug)


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
You'd still need to _declare_ WrapObject in the classes, right?  But the impl could be autogenerated...
I think even the declaration shouldn't be needed.
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)?
(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.
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.

template <class T> nsDOMEventTargetHelper : Binding<T>

And for example WebSocket
class WebSocket : nsDOMEventTargetHelper<WebSocket>, ...
(Obviously I didn't try that approach, but I think something close to it might work.)
So if something inherits from WebSocket you need to templatize it? Not sure how that's much cleaner.
Hmm, yeah, that would be a problem :(
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 :(
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.
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.

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.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.