Would this involve creating a bindingsFoo() for every method foo() that is exposed to bindings? For example, would we have to add XMLHttpRequest::bindingsSend(), even though there's no real need for a special internal XMLHttpRequest::send()? Would getters and setters that map to JavaScript properties (but which do not reflect markup attributes) also need a bindings... version? For example, would we need HTMLMediaElement::bindingsMuted() and HTMLMediaElement::bindingsSetMuted() to wrap the regular muted() and setMuted()?
If the answer to these questions is "yes", then I think this is too much complexity tax on all exposed methods and properties to make up for the benefit. It's likely only a minority of methods where it's highly desirable to have a specialized version for internal use. As a side note, I don't see how this would address the concrete example given, that of firstElementChild likely becoming more efficient than firstChild. If we add bindingsFirstChild() and bindingsFirstElementChild(), how does this help WebCore developers know that they should use the internal firstElementChild() instead of the internal firstChild()? I expect both have to exist, because there really are cases where you need to traverse the whole DOM, not just elements, and even if we were to convert, firstElementChild() is not a drop-in replacement. It also seems to me that internal methods that do the exact same thing as a bindings...() version but lack an ExceptionCode parameter, we'll still want to avoid excess code duplication, in some cases of tricky algorithms. I would not want a second copy of ContainerNode::insertBefore() and its helper methods that replaces exception checking with preflight checks that return false without setting an exeption code (I don't think you can just skip the checks entirely or you'd make a method that is extremely dangerous to call if you have not met very complex preconditions). I do agree with the goal of having efficient internal interfaces that are not constrained by what is exposed to the Web, but a blanket introduction of methods just for bindings does not seem like a good way to get there. Possible alternatives: - Use something in the IDL to call a bindings... variant only in cases where we know there is a materially better internal method. - Use the style checker to ban calling select exposed methods from hand-written WebCore code, and give the corresponding internal methods different names. These approaches could achieve the goals described for critical DOM methods without having to infect things like XHR::send() or HTMLMediaElement::setMuted(). Regards, Maciej On Dec 7, 2012, at 9:27 AM, Darin Adler <[email protected]> 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 > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
