Hi folks.
Many of the APIs designed for use in the DOM are not efficient for use inside
WebKit, or have designs that are better for JavaScript than for C++. Antti
Koivisto and I have been discussing how to best communicate this to WebKit
contributors so they don’t end up using inefficient idioms just because they
are familiar with them from use in JavaScript code on websites. So far, our
best idea for this is to add a prefix to function names that indicate they are
functions for use by the bindings machinery. Thus, a function like appendChild
would get a new name:
void bindingsAppendChild(Node*, ExceptionCode&);
The internal function that’s used to add a child node would be designed for the
best clarity, ease of use, and efficiency within WebKit implementation code,
even when that does not match up with the DOM standard. And could be refactored
over time as WebKit design changes without affecting the bindings.
- It’s not clear what the best prefix is. I don’t like the prefix “dom”, since
it’s a lowercased acronym and an overloaded not all that precise term. The
prefix “bindings” is sort of silly because these functions are not themselves
“bindings”, rather they are the non-language-specific functions designed to be
bound to each language. However, I do like the idea of a brief non-acronym
word. So, still looking for a great prefix.
- When appropriate, these exposed functions can be short inline functions that
turn around and call internal functions.
- These functions aren’t needed at all to implement reflected content
attributes. Hooray!
- So far my best idea on how to stage this is to new inlines without cutting
the bindings over to them. Then cut the bindings generation script over, then
remove and refactor the various unneeded underlying functions. Other ways to
stage this would be add an attribute so we can can switch a class or a function
at a time over to the new naming scheme, but base classes could make that
process challenging and needlessly complex.
- We don’t want to use ExceptionCode& arguments much in internal functions.
They lead both to confusing code and to inefficiency, and I think we can do
much better without them. But they are still probably a good efficient way to
indicate the need for an exception to the JavaScript binding. We’d eliminate
ASSERT_NO_EXCEPTION as part of this.
- This will be particularly helpful for future optimizations, such as one we
are contemplating that will make currently-heavily-used functions such as
firstChild more expensive, and currently-lightly-used functions such as
firstElementChild cheaper. We need a way to rename such things and find
internal callers and prevent people from accidentally undoing that effort as
they do additional WebKit work.
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
