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