<div class="gmail_quote">On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler <span dir="ltr"><<a href="mailto:darin@apple.com">darin@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">From a const Node* you can get:</div>
<br>
    - a non-const pointer to a parent, sibling, or child<br>
    - a non-const pointer to the document<br>
    - a non-const pointer to the renderer<br>
    - a non-const pointer to the style<br>
    - a non-const pointer to various shadow-related ancestors and hosts<br>
<br>
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.</blockquote><div><br></div><div>
>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.</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Further, from the document you can get to the frame and things like the selection controller.<br></blockquote>
<div><br></div><div>Similarly, you shouldn't be able to get non-const pointers to the frame or selection controller from a const document pointer.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>
PK</div></div>