[webkit-dev] Prefix naming scheme for DOM-exposed functions
darin at apple.com
Fri Dec 7 09:27:05 PST 2012
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.
- 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.
More information about the webkit-dev