[webkit-dev] Prefix naming scheme for DOM-exposed functions

[Elliott Sprehn]

This seems like it would introduce bugs and make maintaining the DOM harder
since we'd need to duplicate logic. Right now we have appendChild() and
parserAppendChild(), and using parserAppendChild() for anything not in the
parser introduces web observable bugs and changes in behavior. We also only
have tests for the web exposed methods, unless you're suggesting we add C++
unit tests too? :)

Can you give an example of what you want to change in the non web exposed
appendChild() ?


On Fri, Dec 7, 2012 at 9:27 AM, Darin Adler <darin at apple.com> wrote:

> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121207/d42e6b4a/attachment.html>