On Fri, Dec 7, 2012 at 1:36 PM, Maciej Stachowiak <m...@apple.com> wrote:
> > 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()? > I see no internal clients for HTMLMediaElement::muted()/setMuted() so there would be no need for internal versions for it. I suspect that in many cases we would at most need an internal accessor (which could then properly follow our naming conventions HTMLMediaElement::isMuted()). > 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. > Probably the only way to find out is try doing it and seeing how the patch ends up looking like. > 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. > This would create more freedom for our internal document tree to diverge from how it looks like through the DOM api. For example internal firstChild() that returns Node* may no longer make sense at all if we eliminate Text nodes. antti > 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 <da...@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@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev