[webkit-dev] Do we have a style preference about const member functions?

Darin Adler darin at apple.com
Fri Jun 3 17:27:59 PDT 2011


On Jun 3, 2011, at 9:28 AM, Maciej Stachowiak wrote:

> On Jun 3, 2011, at 7:50 AM, Darin Adler wrote:
> 
>> On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
>> 
>>> All functions passed to enclosingNodeOfType in htmlediting.cpp are such clients:
>>> 
>>> Node* enclosingNodeOfType(const Position& p, bool (*nodeIsOfType)(const Node*), EditingBoundaryCrossingRule rule)
>>> 
>>> It takes a boolean function that takes const pointer to a DOM node.  It is critical that nodeIsOfType does not modify DOM
>> 
>> This points to a place where const does not work well. Having the single node pointer that is the argument to the function be const does not express “must not modify DOM”.
>> 
>> If there was some way to express “must not modify DOM” that would be great, but that just expresses “must not modify this DOM node”.
>> 
>> It happens that the predicate takes a node argument. You could imagine a similar function that takes a Range. You can see that that’s an even clearer. There’s no way to pass a range to a function and also say “must not modify DOM”. I don’t think const is a good way to express this.
> 
> Are you referring to the fact that from a const Node* can be used to get non-const pointers to the Node's neighbors in the DOM, or something else?

Sort of.

From a const Node* you can get:

    - a non-const pointer to a parent, sibling, or child
    - a non-const pointer to the document
    - a non-const pointer to the renderer
    - a non-const pointer to the style
    - a non-const pointer to various shadow-related ancestors and hosts

That’s one problem. Extending the const-ness of the node to mean constness of everything you can get through all these pointers would be a big task, and it’s not clear it would be worthwhile. Further, from the document you can get to the frame and things like the selection controller.

Experience with the C++ standard library taught me that a constant pointer to something within a collection is a difficult concept to model with const. The key example here is the std::vector::erase function. It seems illogical that you can’t call erase on a const_iterator, because the iterator is identifying the location within the vector, not whether you have permission to modify the vector. You’re not modifying something through the iterator. In the same sense, it seems to me that if there is such a thing as a const Node* I should be able to use it to set the selection in a document as long as I have a non-const pointer to that document.

    -- Darin



More information about the webkit-dev mailing list