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

[Peter Kasting]

On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler <darin at apple.com> wrote:

> 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.


>From the perspective of Node itself, I'm not sure why this would be a "big
task".  There shouldn't be any const accessors that return non-const
pointers.  Simply removing the "const" qualifier on all the above accessors
would make things correct, at the expense of possibly making it difficult to
use a const Node*.  Adding const versions of the accessors where necessary,
which themselves vend const pointers, is not significantly harder.

The only way this is a "big task" is if there are callers that make
significant use of const pointers to do non-const actions.  Then we need to
clean these up.  But if they're doing non-const actions, then the cleanup is
simply to make them use non-const pointers.

Further, from the document you can get to the frame and things like the
> selection controller.
>

Similarly, you shouldn't be able to get non-const pointers to the frame or
selection controller from a const document pointer.

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.


Whether or not it's reasonable to have non-const functions on containers,
which modify only the container and not the elements within it, take const
pointers to elements, seems like a separable question from the rest of the
issues with using const correctly.  I happen to find the standard library's
behavior here more reasonable than what you suggest, but regardless, all of
the other cases above could certainly be handled in a "clearly correct"
fashion.

In other words, I don't find this problem a compelling reason to discard the
entire idea of constness when it comes to objects which participate in
tree/graph relationships.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110603/2318b000/attachment.html>