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)
Tracking
()
NEW
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()
Comment 1•12 years ago
|
||
You'd still need to _declare_ WrapObject in the classes, right? But the impl could be autogenerated...
Reporter | ||
Comment 2•12 years ago
|
||
I think even the declaration shouldn't be needed.
Comment 3•12 years ago
|
||
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•12 years ago
|
||
(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.
Reporter | ||
Comment 5•12 years ago
|
||
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>, ...
Reporter | ||
Comment 6•12 years ago
|
||
(Obviously I didn't try that approach, but I think something close to it might work.)
Comment 7•12 years ago
|
||
So if something inherits from WebSocket you need to templatize it? Not sure how that's much cleaner.
Reporter | ||
Comment 8•12 years ago
|
||
Hmm, yeah, that would be a problem :(
Reporter | ||
Comment 9•12 years ago
|
||
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 :(
Reporter | ||
Comment 10•12 years ago
|
||
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•12 years ago
|
||
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•6 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•