Sounds like a good idea in general. On Fri, Dec 7, 2012 at 9:27 AM, Darin Adler <[email protected]> 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
