On Nov 5, 2012, at 5:07 PM, Adam Barth <[email protected]> wrote:
>
> On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak <[email protected]> wrote:
>> Sounds like a good idea. Three additional thoughts:
>>
>> (1) It would be best to choose the objects to apply this to in some
>> data-driven way.
>
> Do you have a suggestion for what data to use? As far as I can tell,
> adding ScriptWrappable as a base class is a win whenever at least half
> of the instances of the object have JavaScript wrappers (in the main
> world):
It's clearly an all-round win for speed and memory when this condition is true.
I imagined some straightforward instrumentation to find classes where this
condition is true (or nearly true) on some representative set of websites.
Applying ScriptWrappable to these classes is definitely pure win.
When the condition is not true (wrapper exists in main world significantly less
than half the time), it's a size-speed tradeoff. It may be worth it in cases if
the memory cost is low and the speed gain is high (for example, one object per
document, but its wrapper is accessed often). That may require some judgment
calls.
>
>> (3) I suspect that we can handle this without adding an IDL attribute at
>> all. C++ overloaded functions could let the bindings do something different
>> for objects that inherit ScriptWrappable from ones that do not in a generic
>> way, without having to explicitly tell the bindings layer about the ways to
>> do it. Consider the ways unwrap() and toJS() are done. We don't have to say
>> anything special in the IDL or have any interface-specific knowledge in the
>> bindings, C++ overloading takes care of it.
>
> Thanks for the suggestion. I got this work (at least for the V8
> bindings---JSC is next on my list). To make something
> ScriptWrappable, you just need to add ScriptWrappable as a base class:
>
> -class DOMImplementation {
> +class DOMImplementation : public ScriptWrappable {
>
> I'm not super excited about the name given that all DOM objects are
> wrappable by script. If folks have thoughts about a better name, I'd
> appreciate suggestions.
I agree with you that the name could use improvement. The only suggestion I can
think of that is not ridiculously verbose would be InlineWrappable, but I am
not sure if that is more clear overall.
Cheers,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
