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

[Antti Koivisto]

On Fri, Dec 7, 2012 at 1:36 PM, Maciej Stachowiak <mjs at 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 <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
>
> _______________________________________________
> 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/20121210/03b1698d/attachment.html>