On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler <da...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
