Open Bug 776383 Opened 12 years ago Updated 2 years ago

Generate code automatically at least for normal WrapObject implementations

Categories

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

x86
Linux
defect

Tracking

()

People

(Reporter: smaug, Unassigned)

References

(Blocks 1 open bug)

Details

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()
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.

then 
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.
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.
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.