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

Ryosuke Niwa rniwa at webkit.org
Fri Dec 7 09:50:59 PST 2012


Sounds like a good idea in general.

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

How about publicAppendChild, exportedAppendChild, apiAppendChild,
exposedAppendChild, or jsAppendChild?

The last one has a benefit of us being able to add alternative functions
like objcAppendChild when Obj-C and JS interfaces are different. i.e.
non-JS bindings falls back to use jsAppendChild by default.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121207/6f950d53/attachment.html>


More information about the webkit-dev mailing list