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

[Hajime Morrita]

(sending from correct address)
Come late here. I basically support Darin's point.

Here is some addition:

As Maciej said, we don't need to do this for all API. We can do this by
opt-in basis, as an optimization.
Since we have [implementedAs] IDL attribute already, we can even start this
today once consensus on prefix naming is made (I'd vote for "binding"
prefix.)

On taking error check apart, another possible idea is to get more help from
our code generators.
For example, we could add "<API Name>Check" C++ function which returns an
ExceptionCode, then we could let generated code call it appropriately.

----
// IDL will look like this:
[IfCheckFail=ReturnNull] readonly attribute Node firstChild;

// generated code will look like this.
ExceptionCode ec = impl->firstChildCheck();
if (ec)
   return jsNull();
return toJS(impl->firstCihld());

// implementation could be
Node* ContainerNode::firstChild() const {
  ASSERT(!firstChildCheck());
  return m_firstChild;
}
----

I expect that there are only a few major patterns for handling and
reporting errors.
So we can also tell such patterns to the generator.

----
// Another IDL example:
[ExceptionIfNull=InvalidStateErorr] readonly attribute Node startContainer
getter raises(DOMException);

// generated code will be something like...
RefPtr<Node> return = impl->startContainer();
if (!return) {
  throwException();
  return jsNull();
}

return toJS(return);
----

This "IDL annotations plus optional C++ helpers" approach isn't as clean
(or simple) as uniform prefixing.
But it could result less hand-written C++ code and achieve same performance
benefit as original proposal.
Its opt-in nature will also help us try these ideas incrementally.

On the other hand, this could possibly result more complex, hard to
understand code backed by half-baked magic, if we do this badly.
I don't think this becomes that complex though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121210/4e2d74eb/attachment.html>